dig +trace +all and it stood out.
> On 3 Mar 2021, at 13:20, Gregory Sloop wrote:
>
> Would you mind showing me how you got there?
> [The answer is fab, obviously. But give a man a fish...and all that. :) ]
>
> -Greg
>
>
>
> MA> The COM servers have stale glue
>
> MA> srvns.pacifier.com.
Let me take a swing at it. If I'm wrong, someone correct me.
1) dig the name servers for the 1st level domain. (In this case, it's a .com.)
# dig +short com. NS
c.gtld-servers.net.
f.gtld-servers.net.
j.gtld-servers.net.
l.gtld-servers.net.
k.gtld-servers.net.
d.gtld-servers.net.
g.gtld-servers.ne
Would you mind showing me how you got there?
[The answer is fab, obviously. But give a man a fish...and all that. :) ]
-Greg
MA> The COM servers have stale glue
MA> srvns.pacifier.com. 172800 IN A 216.65.128.5
MA> webns.pacifier.com. 172800 IN A 216.65.128.1
M
The COM servers have stale glue
srvns.pacifier.com. 172800 IN A 216.65.128.5
webns.pacifier.com. 172800 IN A 216.65.128.1
vs
srvns.pacifier.com. 86400 IN A 64.255.237.241
webns.pacifier.com. 86400 IN A 64.255.237.240
The later se
I've got a case, (and I see several other similar reports) where BIND is
failing to find an A record for a domain.
Yet a dig +trace does.
(I'm doing the dig on the BIND server. It's set to be a root resolving server,
not a forwarder.)
As I understand this, +trace will also involve resolve.conf
You should immediately stop using other people's IP ranges. This won’t ever do
any good. There’s plenty of IP addresses in RFC1918 ranges or even better use
ULA IPv6 range.
When you fix the IP address abuse, there’s a KB article on the topic:
https://kb.isc.org/docs/aa-00800
Ondřej
--
Ondřej S
hey guys,
I'm running a kubernetes cluster which is getting wrong hostnames,
apparently cause my Bind9 is forwarding to a pubic DNS the reverse
resolution of my private network IPs...which happens to be in a public
range that seems to be owned by SoftBankis there. a way to preventing
the DNS t
Greetings.
On Tue, 2 Mar 2021, Adam Augustine wrote:
# ncat -l -U /var/opt/isc/scls/isc-bind/log/named/dnstap.sock
I "chown named.named ./dnstap.sock" :
But regardless I don't get anything from the pipe when using the normal
"systemctl start isc-bind-named.service" followed by some "dig" comman
Well, I don't know what I have done exactly, but now when I start named as
root it seems to be working properly, as far as the pipe goes. I am getting
data via the fstrm_capture process written to the "example.dnstap" file. I
see a number of startup queries when I decode the file.
I can't get it t
Sorry, I replied to just Mark rather than the list.
Yes, here is the command I am using:
# ncat -l -U /var/opt/isc/scls/isc-bind/log/named/dnstap.sock
I "chown named.named ./dnstap.sock" :
0 srwxr-xr-x. 1 named named unconfined_u:object_r:named_log_t:s0 0
Mar 2 09:23 dnstap.sock
But reg
On 2021-02-28 17:52, Mark Andrews wrote:
Domain names without a trailing period are relative to the current
origin.
Domain names with a trailing period are absolute.
snip
On 1 Mar 2021, at 10:41, Tim Daneliuk via bind-users
wrote:
I am trying to understand when the LHS of a TXT record ne
11 matches
Mail list logo
