Re: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread Ondřej Surý
> On 11. 2. 2021, at 7:01, Stuart@registry.godaddy wrote: > > It's one of those old compatibility things. Also called *downgrade attack vector*. Stuart, there’s absolutely no reason to keep any SHA1 in the DNS at the time I am writing this message. Cheers, Ondrej -- Ondřej Surý (He/Him)

Re: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread Mark Elkins
I think getting rid of SHA1 DS (DS type 1) records would be a reasonable thing to do. They are weaker than SHA256 DS (DS type 2) records. Generally, in life, making things simpler is a good idea and I believe that applies here too. .COM only provides DS type 2 records in the root so if there

Re: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread Stuart@registry.godaddy
It's one of those old compatibility things. A quick bit of analysis of the root zone: 1,370 delegations with DS records 697 SHA1 DS records 1,519 SHA2 DS records Yes, these numbers don't add up; there are some double and triple DS record sets in there. So the US zone

Re: Bind 9.11 serving up false answers for a single domain.

2021-02-10 Thread Paul Kosinski via bind-users
I rather prefer tshark to tcpdump: it's essentially the command line version of wireshark, and thus has wireshark's protocol "dissecting" abilities. On Wed, 10 Feb 2021 22:20:08 + "John W. Blue via bind-users" wrote: > Three words: tcpdump and wireshark > > It is like peanut and jelly

RE: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread John W. Blue via bind-users
So out of curiosity why does the us tld have a SHA1 DS in root? Should be an easy thing to tidy up, eh? John -Original Message- From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy] Sent: Wednesday, February 10, 2021 7:20 PM To: John W. Blue; bind-users Subject: Re: Bind 9.11

Re: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread Stuart@registry.godaddy
Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes. Stuart On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users" wrote: Notice: This email is from an external sender. Well .. as best as I can tell .. the us tld does has a SHA1 DS record: ;; QUESTION

RE: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread John W. Blue via bind-users
Well .. as best as I can tell .. the us tld does has a SHA1 DS record: ;; QUESTION SECTION: ;us.IN DS ;; ANSWER SECTION: us. 50882 IN DS 21364 8 1 260D0461242BCF8F05473A08B05ED01E6FA59B9C us. 50882 IN DS

Re: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread Stuart@registry.godaddy
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’ however, is delegated to the state officials of the Commonwealth of Massachusetts and is indeed RSASHA1NSEC3. Stuart ... one of the guy’s that does the DNSSEC for US TLD. From: bind-users on behalf of "John W. Blue via

RE: Bind 9.11 serving up false answers for a single domain.

2021-02-10 Thread John W. Blue via bind-users
Three words: tcpdump and wireshark It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and flow .. pen and paper .. I could go on but … Know them. Love them. They are your newest best friends. Using tcpdump IMHO should be the first tool anyone uses when troubleshooting

Re: Trying again on SERVFAIL

2021-02-10 Thread J Doe
On 2021-02-10 3:05 a.m., Alessandro Vesely wrote: Hi Havard, That's what I've been doing.  For an incoming message, a temporary failure means replying a 4xx code.  The sender keeps the message in its queue, and eventually gives up.  Once upon a time, MTAs used to retry sending for five

Re: Bind 9.11 serving up false answers for a single domain.

2021-02-10 Thread Mark Andrews
Because they are connected at different points in the network and as such see different network faults. The servers can all be working fine, it the connections between them that are not working. -- Mark Andrews > On 11 Feb 2021, at 04:54, sami's strat wrote: > >  > Thank you all for

Re: Bind 9.11 serving up false answers for a single domain.

2021-02-10 Thread sami's strat
Thank you all for responding. One final query about this. I'm seeing this issue on my production servers at work. Yet, when I run the same queries at home, I don't see those failed queries. I actually flushed DNS cache, cleared Linux O/S cache, and even bounced my personal DNS server trying to

Re: Forward zone does not work when allow recursive is restrictive

2021-02-10 Thread Frédéric Lochon
This is very similar to what I wanted to do some time ago, but concluded this is not possible with bind. But, I've modified bind in order to be able to do that anyway. The trick was to use a "static-stub" zone with a small modification in bind code. In my bind-9.16.6, I modified file query.c

NEW on migrating DNSSEC config

2021-02-10 Thread
[Skip to end for some notes on this process and why it was difficult for me.] Just want to double check this before I set off on the next steps in this process, now that the test domain is all setup and everyone is happy and I know where things fell apart in the testing. Hopefully this helps

Re: Trying again on SERVFAIL

2021-02-10 Thread Alessandro Vesely
Hi Havard, thanks for your reply. On Tue 09/Feb/2021 18:15:43 +0100 Havard Eidnes wrote: is there a way to know that a query has already been tried a few minutes ago, and failed? From whose perspective? A well-behaved application could remember it asked the same query a short while ago, of