found in adlists

I guess, so then the problem should be solved by Firefox then since this is all about a choice that Firefox made. Just furthers my resolve that the whole canary domain should be removed from Pi-hole and let users see what Firefox decided to do.


The canary domain is great, I think it can be improved and then everybody can use it. People that just want to add a single /etc/hosts entry, people that use Windows and can add an entry to their HOSTS file, people that use other adblockers....

This is a valid point. However, users will see "Pi-hole is not working". They will not see "Firefox enforces DoH". They will not see this because DoH is completely transparent. They don't know it exists so they cannot complain about it. However, they know Pi-hole exists and (apparently) isn't doing what they want: block ads.

Not handling the canary domain in the way Firefox is happy with would make Pi-hole stop working for the majority of users - the ones with Firefox. So it isn't something I'd like to consider.

My PR adds a patch for something we have forgotten: That blocked content takes precedence over dnsmasq configuration. This is a defect and my PR fixes this for this one special case we have.

Yes. But they have no real motivation to do this. There is no pressing need to, at least. With them not accepting the worst that happens is that Pi-hole doesn't work. May not be all that high in priority for them because really nobody will come and complain about this.

In contrast, whenever such this domain pops up in a adlist, the frustration of Pi-hole users may grow because they cannot find out what is going wrong (again, because they may not even know DoH and its opt-out is even a thing). This leads to frustration and an increase in support load for our team. Both can be easily fixed with my PR completing the canary domain handling in the edge case we have overlooked so far.

To signal that their local DNS resolver implements special features that make the network unsuitable for DoH, network administrators may configure their networks to modify DNS requests for the following special-purpose domain called a canary domain : .


The result will be considered positive if:

  • The query completes with NOERROR and contains A or AAAA records (or both)

A negative result will be a signal to disable application DNS, i.e. DoH.

A is still an A record and, hence, it gets blocked. Think also about other blocking modes Pi-hole offers, say IP blocking. They may even server a real IP address like Hence, we should exclude this domain from being added to gravity. Because it is the simplest, fastest and most reliable way to achieve what we want.

In the end, it is about us wanting that Pi-hole works out of the box with Firefox. It is not Firefox wanting to work best with Pi-hole. So they will not become active but we should.

1 Like

Then we need to stop covering for Firefox and hiding that fact from users. We've said "Hey, Firefox enabling DoH as opt-out is a bad idea. So we're going to add an opt-out feature because when we do it, it's fine."

Is that what they said when they were asked about it?

Then they need to learn about it and we, again, need to stop covering the fact that it's happening.

Which is why this should be passed up to Firefox to address. No one's asked them and this is all on the assumptions that we know what they are going to reply as a response. If someone asks them and they state that they are unwilling to change then we can address things further.

Honestly, it was an "Oh shit" moment that we thought the change by Firefox would render Pi-hole obsolete and we wanted to cover our asses. We didn't do the same with Chrome and QUIC, we just made a FAQ for it and told people to disable QUIC on Chrome.

Can this be changed to a generally applied idea and not specifically targeted at a single domain? Address the defect and not the edge-case.

I don't think we have anything to say here. They will just see Pi-hole is not working. Most of them will not even know that Firefox is part of the problem. Really, Firefox brought us into an unpleasant situation and we're handling

but there was an edge-case where we didn't reply as they expected us to do.

I'm not sure they can handle all the possible solutions. On the other hand, our patch will fix it. And if they add as valid fix, we just shift the problem to another blocking mode:

It could, but how should it look like? Like an additional table in gravity with a statement like (pseudo-SQL):

DELETE FROM gravity WHERE domain IN never_block_these_domains


With only one domain in this list it seems like a lot of overhead we'd have to add. We could still do this at the point when a second domains that needs this comes up. I'm also thinking about future maintainability. Simpler code seems superior at this point (to me).

My simple request:

Ask Firefox.

Someone did

1 Like

I feel good about treating any "local" IP address as a trigger.

Isn't this what I originally suggested (third bullet, first post). When I made that suggestion, something in the back of my head told me I could use this as an alternative for whitelisting, which need to be processed over and over again for each query. No need to whitelist, if it isn't in gravity...

Whitelisting is checked before gravity is even touched. Whitelisting something would still be faster than just a missing item in gravity. Because we stop looking earlier and immediately send upstream.

1 Like

1 year ago

Sounds (to me) a lot like

Does anyone around here have an account over there to bump and hope for a reply? If so, please also ask to add Not sure if they'd consider this "local".

To be fair, nothing is a pressing need until it becomes one.

Earlier, I asked the question, if there are really any users, that use pihole, but really want firefox to use DoH anyway. The answer was YES.

Now, since your both going for 'local' and '', I'm going to ask you this question: What about the users that run their pihole on AWS, or use any other method to host a pihole, NOT using a 'local' address?

Honestly, there is, as far as I know, no data available to indicate the user count for question one (pihole + firefox with DoH), nor for question two (AWS or other solution).

If your going to make decisions on any of these assumptions, you should at least setup some kind of 'request for information' in this pihole community (and reddit). I know, limited audience (ping all users), but it will give you at least some idea of the actual count...

Why would they do that? There's no need to use a public IP address. And we don't support public resolvers.

Sure, we can find edge cases and n=1 situations if we dig hard enough but I would prefer to keep things to less than 100k lines of code.


You asked the question, I gave you the answer. It's up to you if you believe me or not I guess.

Dropping this thread into slow mode (1 post per user per hour) to give everyone a little space to breathe and think about something else for a bit.

It's all been civil enough so far, but we're starting to go back and forth over the same ground - so this is just a precaution to (hopefully) prevent the discussion getting too heated.


Would it be an acceptable solution for all if there would be a selection box in the settings (such as the 'Use DNSSEC' checkbox) that explicitly asks users to 'unblock' the Canary domain, explaining its use?

You could then choose to have it enabled by default and clearly describe the implications of unchecking it.

That way, we are not merely doing things in the background and can point out why this is needed (Firefox!) and make sure the users who are savvy enough can make the right call.

I guess, any setting needs to be fine-grained and allow setting/unsetting per group and not just per installation.

Again, cart before horse. Ask Firefox.

I bumped the topic on Bugzilla. Let's see... I'll post on update.

1 Like