On Wed, 2023-03-15 at 18:58 -0700, ToddAndMargo via users wrote:
Problem. Open DNS is specifically blocking
tor.bravesoftware.com, screwing up my
Brave Browser Private Windows with TOR.
And therein lay a problem with censorship, where someone else has set
the boundary. I can see why they made that decision, though. And I'll
bet that you're going to see far more things blocked than just this.
Q1. that on purpose? Did Fedroa drop /etc/hosts?
As far as I was aware, if you create one it can be used. And it might
be your simplest solution to this problem.
Before I ran a DNS server I became aware that my ISPs DNS server was
terribly slow, and often didn't return results for their own services.
I had to put the IP record for their own usenet server in my hosts
file. That solved that problem. But it was also terrible at resolving
names for everything, so I ended up learning how to use BIND, and have
been running it ever since.
Q2. If I created my own hosts, would it be read first
or after named?
Traditionally hosts was consulted before other measures (making it
useful as an override). The priority of what is consulted to resolve
names is set in /etc/nsswitch.com (name server switch config file).
Scroll down to you find the hosts line. There's often a hashed-out
example, followed by what's actually used. The left-most entry is used
first, and it walks across the line until it finds an answer.
Mine's quite bare:
#hosts: db files nisplus nis dns
hosts: files dns
Q3. Is there a way to hard code tor.bravesoftware.com
into named?
It's possible, though can be unwise (you mightn't know all the info
about the domain you ought to put in, if they change their info you'd
need to change your local version, and it could take some time before
you worked out that had happened).
In /etc/named.conf you'd specify a zone file for the records. I'm
showing an example from something else on my BIND server:
zone "testbed.lan" { type master; file "static/testbed.lan.zone"; };
That filepath would be /var/named/static/testbed.lan.zone on a non-
chrooted system. And on a chrooted system, it's probably:
/var/named/chroot/static/testbed.lan.zone
And in that zone file, you need some basic data, plus the actual domain
name's IPs.
$ORIGIN .
$TTL 86400 ; 1 day
testbed.lan IN SOA ns.testbed.lan hostmaster.testbed.lan (
42 ; serial
300 ; refresh (5 minutes)
900 ; retry (15 minutes)
3600 ; expire (1 hour)
1800 ; minimum (30 minutes)
)
NS ns.testbed.lan.
A 192.168.1.1
MX 1 mail.testbed.lan.
$ORIGIN testbed.lan.
mail A 192.168.1.1
ns A 192.168.1.1
web CNAME www
www A 192.168.1.1
Looking at the data in it, the pertinent bits to a domain, starting at
the third line, there's the domain name, its nameserver address, the
contact address for the record (the first dot is where the @ sign
normally goes). Further down is the NS record, the A record for the
whole domain, the MS record for its mail server. Then some A records
and a CNAME record. You'd have to customise all of that.
If I do a dig request on tor.bravesoftware.com, I get this:
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 <<>> tor.bravesoftware.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50941
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tor.bravesoftware.com. IN A
;; ANSWER SECTION:
tor.bravesoftware.com. 300 IN CNAME d2dy5tljjyhryf.cloudfront.net.
d2dy5tljjyhryf.cloudfront.net. 60 IN A 18.67.111.68
d2dy5tljjyhryf.cloudfront.net. 60 IN A 18.67.111.71
d2dy5tljjyhryf.cloudfront.net. 60 IN A 18.67.111.87
d2dy5tljjyhryf.cloudfront.net. 60 IN A 18.67.111.9
;; AUTHORITY SECTION:
d2dy5tljjyhryf.cloudfront.net. 1830 IN NS ns-1729.awsdns-24.co.uk.
d2dy5tljjyhryf.cloudfront.net. 1830 IN NS ns-831.awsdns-39.net.
d2dy5tljjyhryf.cloudfront.net. 1830 IN NS ns-1165.awsdns-17.org.
d2dy5tljjyhryf.cloudfront.net. 1830 IN NS ns-288.awsdns-36.com.
;; Query time: 1933 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Mar 16 13:23:57 ACDT 2023
;; MSG SIZE rcvd: 291
Which gives you a CNAME and A records you could make use of, as well as
several NS records. Looking at the info, and the nature of tor, I'd
hazard a guess that from one time to another, the CNAME is going to
change, and you'd need all the A records for the new host.
