Hi John.
A few questions, if I may.
- Why *must* you forward everything to Akamai?
- Was that a real example of a daft query: 10.11.12.13 type A? If not, do
you have some real examples of queries being made to your servers please?
- Notwithstanding the nature of these illegal queries, if they *are*
Am 24.01.2023 um 12:15:58 Uhr schrieb John Thurston:
> This comes up because my "resolvers" don't actually resolve. All they
> are allowed to do is forward external queries to Akamai, and accept
> the response from Akamai. And Akamai (thank you very much), is happy
> to accept queries like "What
My "resolvers" running BIND 9.18.10 and 9.16.36, accept and attempt to
resolve queries for illegal names. They will cache answers for these
names, and answer from cache when asked. What's the thinking here?
I suppose it could be, "The specifications of what is a legal name may
change with time
I would be looking for packet loss and / or a bad firewall that is dropping
fragmented packets which is triggering fallback to non EDNS requests If you
are forwarding ensure that the entire forwarding chain is validating.
--
Mark Andrews
> On 25 Jan 2023, at 04:53, John Thurston wrote:
>
>
On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote:
> Hello.
>
> I hope someone could help to understand the following.
>
> I have "my.domain.pt" and a master and slave server for the "my" part. I
> have been using "recursion yes" in both named.conf, as I want them to b
Hi David.
"recursion yes;" tells named that it can (if it has to) make queries to
other places if it needs more information in order to answer a client
query. Pure authoritative servers shouldn't need it and should have
"recursion no;". So the first question is, do your servers make queries out
to
It sounds like I'm correct that lines of the sort:
validating com/SOA: got insecure response; parent indicates it should be
secure
are my indication that dnssec is doing its job. (Whether I should be
reacting to messages like the above remains to be seen.)
Let me rephrase my original questi
Hello.
I hope someone could help to understand the following.
I have "my.domain.pt" and a master and slave server for the "my" part. I
have been using "recursion yes" in both named.conf, as I want them to be
both authoritative and cache for my clients.
Last week I migrated my slave DNS server to
John Thurston wrote:
> On a resolver running ISC BIND 9.16.36 with "dnssec-validation auto;" I am
> writing "category dnssec" to a log file at "severity info;" When I look
in
> the resulting log file, I'm guessing that lines like this:
> validating com/SOA: got insecure respon
Hello,
I don't why DSState: hidden, it's ok with some online check tools like :
- https://dnssec-analyzer.verisignlabs.com/
- https://zonemaster.net/fr/run-test
my master is hidden, it can be related ? How i can debug this DSState:
hidden ?
I found this command to check actual status : rndc dns
I looked in logs of my resolver in my home network and see a similar message
from January 6th:
06-Jan-2023 17:09:23.677 dnssec: info: validating in-addr.arpa/SOA: got
insecure response; parent indicates it should be secure
I interpret that to mean that someone’s DNS is misconfigured. I guess
Hi Adrien,
I don't think it is fine yet. I see in your state file the following line:
> DSState: hidden
This means the DS is not published according to BIND.
> From my understanding, the second KSK should appear because I put the
> parameter "publish-safety 3d;" that is to say 3 days before t
Hello Matthijs,
Indeed I had not published the DS at my registar because I thought that the
second KSK would have appeared anyway at the time of the rollover.
I published the DS yesterday and I reported to BIND with the command you
gave me. I didn't find any error in the logs so everything must h
13 matches
Mail list logo
