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.

-- 
 
uname -rsvp
Linux 3.10.0-1160.83.1.el7.x86_64 #1 SMP Wed Jan 25 16:41:43 UTC 2023 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to