Por vários motivos, principalmente relacionados à segurança e privacidade, eu ficaria mais feliz se meu bind9 somente em cache usasse somente TCP para fazer conexões externas.
Claro, ele deve ser capaz de aceitar e manipular consultas UDP.
Como posso fazer isso?
usuário@nextcloudpi:/$sudo certbot -d downwind.duckdns.org --manual --preferred-challenges dns certonly~
retornou:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.downwind.duckdns.org with the following value:
to8BGF9LfNEOTdZkJAMUYoEd0rROw8Zwa6dumWVBIvA
Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Como estou tentando configurar o certificado para o duckdns, tentei:
Gostaria de verificar se o certificado está operacional. Existe algum teste de linha de comando que possa ser executado remotamente?
O Verificador SSL retorna:
O resultado indica uma instalação bem-sucedida do certificado?
Analisei várias resolve.confperguntas aqui e em outras documentações, mas elas falam sobre o DNS como algo externo, o que não me ajuda a distinguir neste caso.
/etc/resolve.confque contém dois outros endereços IP.Esses outros IPs em resolve.conf devem ser os 2 que apontam para o servidor ou devem ser 2 IPs "estranhos" apontando para o upstream?
Obrigado
Tenho bind9 em execução para DNS LAN local. Também tenho um servidor de cache APT. Então, configurei um arquivo RPZ para envenenar certos nomes de domínio e fazer com que eles sejam resolvidos para meu servidor de cache interno. A execução de eg apt updateestá retornando erros de resolução , acho que porque o servidor de cache não consegue resolver os registros verdadeiros (externos) e buscar os dados. Acho que isso significa que eu teria que configurar uma visualização para o servidor de cache como /32.
Então a questão é, posso configurar para que meu servidor de cache que atinge domínios na zona envenenada seja apenas encaminhado, enquanto o resto da rede recebe os dados envenenados? Só não tenho certeza de como fazer isso.
Recentemente, configurei um novo servidor DNS usando o Bind (v9.18.28-1) e estou recebendo blocos repetidos de erros no meu arquivo de log "geral":
02-Oct-2024 09:49:09.723 resolver: DNS format error from 2001:7fe::53#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.755 resolver: DNS format error from 2001:dc3::35#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.787 resolver: DNS format error from 2001:500:2f::f#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.819 resolver: DNS format error from 2001:500:12::d0d#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.851 resolver: DNS format error from 2001:503:c27::2:30#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.883 resolver: DNS format error from 2001:500:2::c#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.919 resolver: DNS format error from 2001:500:2d::d#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.951 resolver: DNS format error from 2001:7fd::1#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.991 resolver: DNS format error from 2001:500:9f::42#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.027 resolver: DNS format error from 2801:1b8:10::b#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.059 resolver: DNS format error from 2001:500:a8::e#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.095 resolver: DNS format error from 2001:500:1::53#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.127 resolver: DNS format error from 2001:503:ba3e::2:30#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.163 resolver: DNS format error from 192.36.148.17#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.183 resolver: DNS format error from 202.12.27.33#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.207 resolver: DNS format error from 192.5.5.241#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.227 resolver: DNS format error from 192.112.36.4#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.251 resolver: DNS format error from 192.58.128.30#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.275 resolver: DNS format error from 192.33.4.12#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.299 resolver: DNS format error from 199.7.91.13#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.323 resolver: DNS format error from 193.0.14.129#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.347 resolver: DNS format error from 199.7.83.42#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.371 resolver: DNS format error from 170.247.170.2#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.395 resolver: DNS format error from 192.203.230.10#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.423 resolver: DNS format error from 198.97.190.53#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.447 resolver: DNS format error from 198.41.0.4#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.447 resolver: resolver priming query complete: failure
Parece que esses são todos os servidores de nomes raiz que listei no arquivo /usr/share/dns/root.hints.
Este arquivo é referenciado por meio deste bloco de zona no meu arquivo de configuração nomeado:
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
Aqui estão as opções que configurei:
options {
directory "/var/cache/bind";
allow-query {
any;
};
forwarders {
1.1.1.1;
};
allow-recursion {
xx.xx.xx.xx/29;
//10.0.0.0/8;
10.1.0.0/16;
};
// hide version #
version "unknown";
dnssec-validation auto;
};
Alguma ideia do que está causando esses erros de formatação e há algo que eu possa fazer a respeito?
Obrigado, pessoal!
Se eu modificar meu /etc/hostsarquivo a partir disso:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
para isso:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
127.0.0.1 www.microsoft.com
Isso redirecionará qualquer tentativa de acesso www.microsoft.coma 127.0.0.1, bloqueando efetivamente o acesso a www.microsoft.com. Isso funciona muito bem.
Agora, em vez de redirecionar para localhost, quero redirecionar para outro site, por exemplo, quero alterar meu /etc/hosts para ficar assim:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
www.google.com www.microsoft.com
No entanto, quando tento visitar www.microsoft.com, ele nunca me redireciona para www.google.com. Ele simplesmente vai direto para www.microsoft.come ignora o que eu fiz em /etc/hosts.
Alguém sabe como consertar isso ou como isso pode ser alcançado?
Alterar a opção DNS em resolve.conf do gateway das VMs para 8.8.8.8 resultará em nenhuma resolução de DNS.
resolvctl query google.comterá êxito se eu definir o DNS para meu gateway.
[Correspondência]
Nome=enp0s3
[Rede]
Endereço=192.168.0.222/24
Gateway=192.168.0.1
DNS=8.8.8.8
Meu Turris Omnia não consegue resolver t.co, mas não tem problemas com outros domínios como twitter.com ou x.co. Os nomes locais (hpdisk.lan) também funcionam:
root@turris:~# ping t.co
ping: t.co: Name does not resolve
root@turris:~# ping twitter.com
PING twitter.com (104.244.42.193) 56(84) bytes of data.
64 bytes from 104.244.42.193 (104.244.42.193): icmp_seq=1 ttl=58 time=11.5 ms
tange@turris:~$ ping x.co
PING x.co (148.72.51.157) 56(84) bytes of data.
64 bytes from 157.51.72.148.host.secureserver.net (148.72.51.157): icmp_seq=1 ttl=42 time=139 ms
tange@turris:~$ ping hpdisk.lan
PING hpdisk.lan (192.168.1.30) 56(84) bytes of data.
64 bytes from 192.168.1.30 (192.168.1.30): icmp_seq=1 ttl=64 time=0.374 ms
O roteador não tem problemas em consultar os servidores de nomes de autenticação, portanto, não é causado por algum problema de filtragem ou roteamento de rede:
root@turris:/tmp/log# dig @a.r06.twtrdns.net. t.co
; <<>> DiG 9.18.24 <<>> @a.r06.twtrdns.net. t.co
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13597
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;t.co. IN A
;; ANSWER SECTION:
t.co. 300 IN A 104.244.42.197
Pesquisar u.co causa esse tráfego (e bastante semelhante para [as,uz].co):
14:36:00.469554 IP 100.100.246.190.51757 > 156.154.105.25.53: 20216% [1au] A? U.CO. (33)
14:36:00.484396 IP 156.154.105.25.53 > 100.100.246.190.51757: 20216- 0/6/1 (639)
14:36:00.485495 IP 100.100.246.190.55245 > 193.108.91.245.53: 25634% [1au] A? Ns50.DoMAInCoNtROL.COm. (51)
14:36:00.500380 IP 193.108.91.245.53 > 100.100.246.190.55245: 25634*- 1/0/1 A 173.201.72.25 (67)
14:36:00.500659 IP 100.100.246.190.60650 > 173.201.72.25.53: 49104% [1au] A? U.Co. (33)
14:36:00.513975 IP 173.201.72.25.53 > 100.100.246.190.60650: 49104*- 2/2/1 A 15.197.142.173, A 3.33.152.147 (120)
Procurar t.co não causa tráfego. Parece que o Knot Resolver pensa que é autorizado para t.co
Eu tentei reiniciar o roteador. Isso não resolveu o problema.
root@turris:~# uname -a
Linux turris 5.15.148 #0 SMP Tue Apr 2 01:04:13 2024 armv7l GNU/Linux
root@turris:~# kresd --version
Knot Resolver, version 5.7.1
root@turris:~# netstat -anp |grep 0:53
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 18768/kresd
udp 0 0 0.0.0.0:53 0.0.0.0:* 18768/kresd
tange@turris:~$ cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
nameserver ::1
root@turris:/tmp/log# cat /var/log/resolver
Apr 27 11:52:30 turris kresd[8728]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
Apr 27 11:52:50 turris kresd[12702]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
Não encontrei nenhum navegador que suporte aliases definidos, /etc/hostsmesmo quando termos únicos (sem precisar acrescentar no navegador http://) não são interpretados como termos de pesquisa para o mecanismo de pesquisa padrão (o caso de badwolf browser ). Aliases funcionam quando prefixados com http://, por exemplo,
http://bsemas ter que digitar http://anula o propósito de usá-los.
A Cloudflare não permite acessar bitcoin.stackexchange.com por meio de um alias, definido como 172.64.144.30 bitcoin.stackexchange.com bse
Error 1003 Ray ID: 85750e9fc9b65e4d • 2024-02-18 08:56:29 UTC
Direct IP access not allowed
What happened?
You've requested an IP address that is part of the Cloudflare network. A valid Host header must be supplied to reach the desired website.
Quando tento acessar, bitcoin.stackexchange.comnão recebo nenhum erro do Cloudflare.
Estou enviando um cabeçalho de host ao tentar acessar bitcoin.stackexchange.comde um PC de mesa com 172.64.144.30 bitcoin.stackexchange.com bseanexo /etc/hosts?
Por que obtenho um comportamento diferente do navegador ao tentar acessar http://bsee bitcoin.stackexchange.comentrar no navegador?
Há alguma configuração em navegadores como Brave, Firefox ( about:config?), Chromium que eu possa aplicar para usar meus aliases perfeitamente?
Além das /etc/hostsminhas consultas de DNS, as consultas são resolvidas pelo roteador doméstico, conforme mostrado pelo conteúdo do meu/etc/resolv.conf
# Generated by Connection Manager
search home
nameserver 192.168.1.1
A pesquisa que fiz é man hosts. O objetivo hipotético de anexar 172.64.144.30 bitcoin.stackexchange.com bseé /etc/hostslimitar o número de determinadas consultas DNS (que podem fazer meu perfil parecer muito radical e, portanto, resultar em vigilância direcionada) ao servidor DNS do meu roteador. Estou ciente da possibilidade de pesquisas reversas de DNS, mas deixo isso fora do escopo da questão.
Ao executar digvocê pode especificar um "servidor" (o servidor DNS no qual você faz a consulta), "domínio" e "host". Como "host" não é opcional, acho que é isso que você está tentando resolver. Mas você também pode especificar um “domínio”. Achei que poderia ser, se tomarmos unix.stackexchange.comcomo exemplo, o "host" poderia ser unixe o "domínio" poderia ser stackexchange.com, porém dig stackexchange.com unixnão pareceu recuperar os registros DNS para unix.stackexchange.com.
O "host" e o "domínio" aos quais me refiro são os listados nas linhas de ajuda abaixo.
(Para esclarecer, sei que dig unix.stackexchange.comfunciona, estou perguntando sobre o significado de "host" e "domínio" nas linhas de ajuda do dig)
$ dig -v
DiG 9.16.44-Debian
$ dig -h
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Where: domain is in the Domain Name System
q-class is one of (in,hs,ch,...) [default: in]
q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a]
(Use ixfr=version for type ixfr)
q-opt is one of:
-4 (use IPv4 query transport only)
-6 (use IPv6 query transport only)
-b address[#port] (bind to source address/port)
-c class (specify query class)
-f filename (batch mode)
-k keyfile (specify tsig key file)
-m (enable memory usage debugging)
-p port (specify port number)
-q name (specify query name)
-r (do not read ~/.digrc)
-t type (specify query type)
-u (display times in usec instead of msec)
-x dot-notation (shortcut for reverse lookups)
-y [hmac:]name:key (specify named base64 tsig key)
d-opt is of the form +keyword[=value], where keyword is:
+[no]aaflag (Set AA flag in query (+[no]aaflag))
+[no]aaonly (Set AA flag in query (+[no]aaflag))
...
global d-opts and servers (before host name) affect all queries.
local d-opts and servers (after host name) affect only that lookup.
-h (print help and exit)
-v (print version and exit)