Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

[stuart@registry.godaddy]

The crypto policy stuff ultimately creates and maintains files in 
/etc/crypto-policy/backends, which has a list of acceptable or not-acceptable 
crypto settings.

Whilst a "bind.config" is created, you aren't including it in your config (this 
is fine), which suggests that the issue is with some of openssl configurations 
(which will be system wide anyway).

You can use the update-crypto-policies to update only the openssl configuration 
to allow sha1, or you could manually recreate those files (instead of the usual 
symlinks) and edit them individually as you please.

Stuart

From: bind-users  on behalf of John Thurston 

Date: Thursday, 18 April 2024 at 06:39
To: "bind-users@lists.isc.org" 
Subject: Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

Arrgh. You are correct. I was so far down in the weeds, I didn't notice a rock 
had fallen on my head.
I know I can re-enable SHA1 for everything on the host with:
update-crypto-policies --set DEFAULT:SHA1
But that's a fairly broad stroke, when only 'named' needs to accept such 
signatures. Is there a way to narrow it down?

--
Do things because you should, not just because you can. 

John Thurston907-465-8591
mailto:john.thurs...@alaska.gov
Department of Administration
State of Alaska
On 4/17/2024 9:21 AM, Ondřej Surý wrote:
Let me guess - you are running on RHEL (without SHA-1 support) and 
dnssec-failed.org is signed with RSA/SHA-1…

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How do I debug if the queries are not getting resolved?

[stuart@registry.godaddy]

> Subject: Re: How do I debug if the queries are not getting resolved?
> 
> Oh I forgot to tell you that. This is BIND RPZ and all the queries are 
> recursive. 
> 
> Dig output just dies out and does not spit anything.
> 
> And this specifically i noticed with .gov and .gov.in domain. This is the 
> reason I thing it might be related with DNSSEC.

Given that there's no implicit RPZ related to .gov or .gov.in, can you please 
provide us with some concreate examples of what you're trying to achieve?

> Also wanted to understand overall how do I debug any queries.

What you've described so far is the inability to reach your recursing name 
server, i.e. the very first step.

You've not mentioned what OS you're doing these tests from, so we can't direct 
you with specifics, just very broad and imprecise steps.

Namely:

- Check what name server your host is configured to use.
- Using the "dig" command with a "@[ip-address]", verify that you can actually 
ask that server queries. i.e.

dig @127.0.0.1 www.google.com. IN A

- Verify that you're asking a correct question by looking at the "Question" 
section of the output. i.e. 

;; QUESTION SECTION:
;www.google.com. IN A

- Verify that the response you received is not an error of some kind, i.e.:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54894
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

- If you're the one running the recursing name server, verify that no errors 
occurred in the log files.

Etc.

For us to help you further, please give us specific information, otherwise 
we're just fishing around to try give you relevant information.

> On Tue, Dec 12, 2023, 00:28 Marco Moock  > wrote:
> Am 11.12.2023 um 23:37:36 Uhr schrieb Blason R:
> 
> > I require assistance in troubleshooting the resolution issue for
> > specific domains that are not being resolved properly. The version of
> > BIND I am currently using is BIND 9.18.20-1.
> 
> First, tell us if those queries are authoritative on that server or not.
> 
> Try using dig and post the output here.
> -- 

Stuart

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Facing issues while resolving only one record

[stuart@registry.godaddy]

This is odd.

“incometax.gov.in” hasn’t published a DS record, so no DNSSEC validation should 
be occurring for any child. The registry object hasn’t been changed since 2022, 
so its behaviour should be nothing new.

Testing various public verifying resolvers (google, cloudflare, local unbound 
instances) shows no issue retrieving an A record for eportal.incometax.gov.in., 
from many places around the world (nlnog ring nodes).

So, weird.


Stuart Browne
GoDaddy Registry | Eng - System IV
[signature_3682002026]
stuart@registry.godaddy<mailto:stuart@registry.godaddy>

i.e. I’m one of the people who maintains the registry and DNS servers for “in” 
/ “gov.in”.

From: bind-users  on behalf of Blason R 

Date: Thursday, 31 August 2023 at 1:42 pm
To: "Bhangui, Sandeep - BLS CTR" 
Cc: bind-users 
Subject: Re: Facing issues while resolving only one record

You don't often get email from blaso...@gmail.com. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.


Yes, bypassing DNSSEC Validation seems to have a solution.

Thanks for the help.

On Wed, Aug 30, 2023 at 7:30 PM Bhangui, Sandeep - BLS CTR via bind-users 
mailto:bind-users@lists.isc.org>> wrote:
This seems to be an issue with the domain 
incometax.gov.in<http://incometax.gov.in/>.

DNSSEC looks like is broken for that domain.

NS servers at our location also cannot resolve that directly  but if I forward 
that query to any ISP provider NS which are more lax it resolves just fine.

Thanks
Sandeep

From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> On 
Behalf Of John W. Blue via bind-users
Sent: Wednesday, August 30, 2023 9:39 AM
To: bind-users mailto:bind-users@lists.isc.org>>
Subject: RE: Facing issues while resolving only one record

CAUTION: This email originated from outside of BLS. DO NOT click (select) links 
or open attachments unless you recognize the sender and know the content is 
safe. Please report suspicious emails through the “Phish Alert Report” button 
on your email toolbar.
Recommend you turn off DNSSEC validation and see if it starts working.

If it does, then you know the issue is with how DNSSEC is configured on your 
server.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Blason R
Sent: Wednesday, August 30, 2023 8:20 AM
To: bind-users
Subject: Facing issues while resolving only one record

Hi all,

I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support Version)
And I am facing this weird issue. Somehow 
eportal.incometax.gov.in<http://eportal.incometax.gov.in/> site is not getting 
resolved through DNS.

I tried a lot but unfortunately the issue still persists.

Here are packet capture logs.

listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 
262144 bytes
18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+ A? 
eportal.incometax.gov.in<http://eportal.incometax.gov.in/>. (42)
18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53: 30627+% 
[1au] A? eportal.incometax.gov.in<http://eportal.incometax.gov.in/>. (65)
18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+% [1au] 
DNSKEY? incometax.gov.in<http://incometax.gov.in/>. (57)
18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+% [1au] 
DNSKEY? incometax.gov.in<http://incometax.gov.in/>. (57)
18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+ ? 
eportal.incometax.gov.in<http://eportal.incometax.gov.in/>. (42)
18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+% [1au] 
? eportal.incometax.gov.in<http://eportal.incometax.gov.in/>. (65)
18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53: 16204+% 
[1au] DNSKEY? incometax.gov.in<http://incometax.gov.in/>. (57)
18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53: 34205+% 
[1au] ? eportal.incometax.gov.in<http://eportal.incometax.gov.in/>. (65)
18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+% [1au] 
DNSKEY? incometax.gov.in<http://incometax.gov.in/>. (57)
18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+ A? 
eportal.incometax.gov.in<http://eportal.incometax.gov.in/>. (42)
18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349 [1au] 
DNSKEY? incometax.gov.in<http://incometax.gov.in/>. (57)
18:47:25.205136 ens18 Out IP 192.168.1.133.33517 > 192.36.148.17.53: 18768 
[1au] DNSKEY? incometax.gov.in<http://incometax.gov.in/>. (57)
18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53: 28883 
[1au] DNSKEY? incometax.gov.in<http://incometax.gov.in/>.

Re: Bind 9.16.1 crash

[stuart@registry.godaddy]

As the package maintained by the Ubuntu team are “no longer” the source from 
ISC (but highly modified patches onto an old 9.16.1 source tree), I’d suggest 
following up with the Ubuntu maintainers of the package, as it’s likely their 
back-porting of security patches from much more recent releases is the cause of 
the issue.

Stuart

From: bind-users  on behalf of Ben Bridges 

Date: Thursday, 8 December 2022 at 11:04 am
To: Emmanuel Fusté , "bind-users@lists.isc.org" 

Subject: RE: Bind 9.16.1 crash

According to the Ubuntu maintainers, the bind9 package on our server 
(1:9.16.1-0ubuntu2.11) is fully patched for all the BIND 9 CVE’s including the 
latest batch of 6 released on 2022-09-21 (CVE-2022-38178, CVE-2022-38177, 
CVE-2022-3080, CVE-2022-2906, CVE-2022-2881, and CVE-2022-2795).


From: Emmanuel Fusté 
Sent: Wednesday, December 7, 2022 4:22 PM
To: Ben Bridges ; bind-users@lists.isc.org
Subject: Re: Bind 9.16.1 crash

Current ESV : 9.16.35

No, your release is not patched.
Add the ISC PPA repo and install the latest ESV. ISC PPA packaged are packaged 
by the same maintainers.

Le mer. 7 déc. 2022, 23:02, Ben Bridges 
mailto:bbrid...@springnet.net>> a écrit :
Ubuntu 20.04.5 is LTS and BIND 9.16 is the current stable ESV release, so 
they’re both still fully supported (and fully patched).
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Possible to condition a view based on the interface the query comes in on?

[stuart@registry.godaddy]

Look in to "match-destination" in a view, i.e.

acl abcd.anycast {
10.10.10.1; 
};
view "abcd" {
match-clients {
any;
};
match-destinations {
abcd.anycast;
};
...
};

The response-policy definition (and associated zone) can go into a view, 
instead of global options.

Stuart

On 19/11/21, 7:40 am, "bind-users on behalf of Fred Morris" 
 wrote:

[You don't often get email from m3...@m3047.net. Learn why this is 
important at http://aka.ms/LearnAboutSenderIdentification.]

Caution: This email is from an external sender. Please do not click links 
or open attachments unless you recognize the sender and know the content is 
safe. Forward suspicious emails to isitbad@.



I wanted to provide enhanced recursive DNS to (internal) clients on an
"opt in" basis, which is to say that clients could choose whether or not
to receive enhanced replies based on what they configured as their local
caching resolver. The enhanced services come in the form of a Response
Policy Zone (RPZ).

Didn't see any reason that it had to be separate instances of BIND,
thought maybe I could do it with views, but I've run into a couple of
roadblocks:

1. listen-on isn't supported in views.
2. internet wisdom augurs that response-policy isn't supported either.

Is there a way to do this or should I bite the bullet and run two copies
of BIND?

Thanks in advance...

--

Fred Morris


___
Please visit 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gjtq6vOlM%2BQIHcqfrVgJD%2Fzbjm3vLdF%2BKg74%2FtPQsuA%3D&reserved=0
 to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2F&data=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xptHiGDaNrn7P99mhYJrI%2Fbw2nAf%2FH7%2FJCRFUvabkrc%3D&reserved=0
 for more information.


bind-users mailing list
bind-users@lists.isc.org

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gjtq6vOlM%2BQIHcqfrVgJD%2Fzbjm3vLdF%2BKg74%2FtPQsuA%3D&reserved=0


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to start name

[Stuart@registry.godaddy]

> From: bind-users  on behalf of rams 
> 
> Date: Friday, 9 April 2021 at 2:56 pm
> To: bind-users 
> Subject: Unable to start name

> Hi  
> We are using bind 9.11.28.1 on centos7.8. We have large number of zones
> on disk. When we stop/start , we are not getting successful message and
> seeing below error. But in log we see named is running and doing
> axfr/ixfr. Do we need to add any configuration paameter to avoid below
> error.
> 
> Starting named (via systemctl):  Job for named.service failed because a 
> timeout was exceeded. See "systemctl status named.service" and "journalctl 
> -xe" for details

You mentioned that you have a large number of zones. If there are no error
messages generated by NAMED starting other than the exceeding of a timeout,
it could just be the system service-start timing out.

Have a look at TimeoutSec in the service unit definition:

https://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutSec=

You may also want to try "named-checkconf -z /etc/named.conf" and see how long
it takes (as this does a similar sort of validation as starting the service 
does).

Stuart

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: replication time for dynamic records from primary to secondary servers

[Stuart@registry.godaddy]

On 31/3/21, 8:00 am, "bind-users on behalf of John Thurston" 
 wrote:


On 3/30/2021 12:30 PM, Cuttler, Brian R (HEALTH) via bind-users wrote:
> We are seeing a delay in the primary DNS server updating the secondary 
and would like to shorten that interval.

Can you post the pertinent bits of your primary's and secondary's config
for the zone?

In the absence of that, I pose a few questions:

How long is it taking now?
What is your target interval?

Do you have NOTIFY enabled on the primary?
How large is the zone?
If you look in the log, do you see XFRs queuing?
How many secondaries are there?
Do you have limits defined on the number of simultaneous transfers?

Additional question, do you have "notify-delay" defined?

Stuart

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Stuart@registry.godaddy]

Good to know.

Will attach a task to the next our next KSK roll process. Should halve the 
number of SHA1 DS's in the root.

Will also tweak some of our other DNSSEC process documentation to stop 
providing them.

Stuart

On 11/2/21, 6:49 pm, "bind-users on behalf of Ondřej Surý" 
 wrote:

Notice: This email is from an external sender.



> 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)
ond...@isc.org



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Stuart@registry.godaddy]

I was going to throw out a “Of course not”, but after having a bit of a 
stressful last few hours, I decided to walk the zone manually as something 
“brainless” to relax..

And found there are some.. 

firmdale (RSASHS256 DNSKEY algorithm (8))
gdn (RSASHS256 DNSKEY algorithm (8))
na (RSASHA1 (NSEC) DNSKEY algorithm (5))

It seems there's some old hold outs..

But that's enough root zone walking for me for a while.

Stuart

From: Mark Elkins 
Date: Thursday, 11 February 2021 at 6:42 pm
To: Stuart Browne , bind-users 

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

Notice: This email is from an external sender. 
 
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 were fundamental 
problems - we would have heard by now.
@Stuart - So do any delegations in the root zone only have SHA1 DS records?
On 2/11/21 8:01 AM, mailto:Stuart@registry.godaddy wrote:
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 is by no means alone in keeping it around (at least 27 other 
countries similarly have them).

I'm sure that in the not-too-distant future, they'll be phased out, but for now 
we don't have that as an high priority piece of work.

Stuart

On 11/2/21, 1:06 pm, "bind-users on behalf of John W. Blue via bind-users" 
mailto:bind-users-boun...@lists.isc.orgonbehalfofbind-us...@lists.isc.org wrote:

Notice: This email is from an external sender.



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: mailto: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 serving up false answers for a single domain. (OT)

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" 
mailto:bind-users-boun...@lists.isc.orgonbehalfofbind-us...@lists.isc.org 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 SECTION:
;us.IN  DS

;; ANSWER SECTION:
us. 50882   IN  DS  21364 8 1 
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882   IN  DS  21364 8 2 
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26

Right?

In checking other tld's looks like it is a mixed bag .. some do .. some 
don’t.

;; QUESTION SECTION:
;com.   IN  DS

;; ANSWER SECTION:
com.78577   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

-Original Message-
From: mailto:Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. 
(OT)



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 mailto:bind-users-boun...@lists.isc.org on behalf of 
"John W. Blue via bind-users" mailto:bind-users@lists.isc.org Reply to: "John 
W. Blue" mailto:john.b...@rrcic.com
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users mailto:bind-users@lists.isc.org
Subject: RE: Bind 9.11 serving up false answers for a single domain.

Notice: This email is from an external sender.

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 seemly unexplainable DNS weirdness.

Knowing what is being put on the wire (or lack thereof) is critical 
since it provides key factual data points that decisions can be made on.  When 
running tcpdump on the DNS server I personally prefer this command:

tcpdump -n -i  -s 65535 -w 

   

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

[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 is by no means alone in keeping it around (at least 27 other 
countries similarly have them).

I'm sure that in the not-too-distant future, they'll be phased out, but for now 
we don't have that as an high priority piece of work.

Stuart

On 11/2/21, 1:06 pm, "bind-users on behalf of John W. Blue via bind-users" 
 wrote:

Notice: This email is from an external sender.



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 serving up false answers for a single domain. (OT)

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 SECTION:
;us.IN  DS

;; ANSWER SECTION:
us. 50882   IN  DS  21364 8 1 
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882   IN  DS  21364 8 2 
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26

Right?

In checking other tld's looks like it is a mixed bag .. some do .. some 
don’t.

;; QUESTION SECTION:
;com.   IN  DS

;; ANSWER SECTION:
com.78577   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

    -Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. 
(OT)



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 bind-users"  Reply to: "John W. Blue" 

Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users 
Subject: RE: Bind 9.11 serving up false answers for a single domain.

Notice: This email is from an external sender.

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 seemly unexplainable DNS weirdness.

Knowing what is being put on the wire (or lack thereof) is critical 
since it provides key factual data points that decisions can be made on.  When 
running tcpdump on the DNS server I personally prefer this command:

tcpdump -n -i  -s 65535 -w 

dash n is telling tcpdump that you do not want it to resolve hostnames. 
 This is an important option when doing DNS troubleshooting because you do not 
want extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.

After starting the command, run several queries from a host and ctrl+c 
to exit.

Once you get your file into wireshark now you can start slicing n 
dicing on the data!

Here is handy wireshark filter:  dns.qry.name == 
internet-dns1.state.ma.us

By using a filter of dns.flags.rcode == (number here) you can drive off 
into the weeds and get super granular with sorting the data.  For example 
“dns.flags.rcode == 2” will show you all of the server failures for queries.

It is hard to provide further guidance on what to do since what you 
find in the pcap is only a starting point.

Good hunting!

As an aside I would like to mention that you do not need to travel home 
to get situational awareness when the diggui.com website can be used instead.

Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?

https://dnsviz.net/d/state.ma.us/dnssec/

John



From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
sami's strat
 

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

[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 SECTION:
;us.IN  DS

;; ANSWER SECTION:
us. 50882   IN  DS  21364 8 1 
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882   IN  DS  21364 8 2 
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26

Right?

In checking other tld's looks like it is a mixed bag .. some do .. some 
don’t.

;; QUESTION SECTION:
;com.   IN  DS

;; ANSWER SECTION:
com.78577   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

-Original Message-
    From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)



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 bind-users"  Reply to: "John W. Blue" 

Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users 
Subject: RE: Bind 9.11 serving up false answers for a single domain.

Notice: This email is from an external sender.

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 seemly unexplainable DNS weirdness.

Knowing what is being put on the wire (or lack thereof) is critical since 
it provides key factual data points that decisions can be made on.  When 
running tcpdump on the DNS server I personally prefer this command:

tcpdump -n -i  -s 65535 -w 

dash n is telling tcpdump that you do not want it to resolve hostnames.  
This is an important option when doing DNS troubleshooting because you do not 
want extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.

After starting the command, run several queries from a host and ctrl+c to 
exit.

Once you get your file into wireshark now you can start slicing n dicing on 
the data!

Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us

By using a filter of dns.flags.rcode == (number here) you can drive off 
into the weeds and get super granular with sorting the data.  For example 
“dns.flags.rcode == 2” will show you all of the server failures for queries.

It is hard to provide further guidance on what to do since what you find in 
the pcap is only a starting point.

Good hunting!

As an aside I would like to mention that you do not need to travel home to 
get situational awareness when the diggui.com website can be used instead.

Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?

https://dnsviz.net/d/state.ma.us/dnssec/

John



From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
sami's strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.

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 reproduce 
the issue.  But I could not.

TIA

On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org> wrote:
Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you 
the glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us 
@’ for all the addresses in the glue records.

e.g.
dig +dnssec +norec http://internet-dns1.state.ma.us 
@http://146.243.122.17

Mark

> On 10 Feb 2021, at 14:50, sami's strat <mailto:sami.st...@gmail.com> 
wrote:
>
> Thanks Mark.
>
> However, the traceroute to the hostnamed failed for the same reason.  
Please note:
>
> [root@myhost data]# dig http://internet-dns1.state.ma.us
> 
> ; <<>> DiG 9.11.4-P2-RedH

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

[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 bind-users" 
Reply to: "John W. Blue" 
Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users 
Subject: RE: Bind 9.11 serving up false answers for a single domain.

Notice: This email is from an external sender. 
 
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 
seemly unexplainable DNS weirdness.
 
Knowing what is being put on the wire (or lack thereof) is critical since it 
provides key factual data points that decisions can be made on.  When running 
tcpdump on the DNS server I personally prefer this command:
 
tcpdump -n -i  -s 65535 -w 
 
dash n is telling tcpdump that you do not want it to resolve hostnames.  This 
is an important option when doing DNS troubleshooting because you do not want 
extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.
 
After starting the command, run several queries from a host and ctrl+c to exit.
 
Once you get your file into wireshark now you can start slicing n dicing on the 
data!
 
Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us
 
By using a filter of dns.flags.rcode == (number here) you can drive off into 
the weeds and get super granular with sorting the data.  For example 
“dns.flags.rcode == 2” will show you all of the server failures for queries.
 
It is hard to provide further guidance on what to do since what you find in the 
pcap is only a starting point.
 
Good hunting!
 
As an aside I would like to mention that you do not need to travel home to get 
situational awareness when the diggui.com website can be used instead.
 
Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?
 
https://dnsviz.net/d/state.ma.us/dnssec/
 
John
 
 
 
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of sami's 
strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.
 
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 reproduce 
the issue.  But I could not.
 
TIA
 
On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews  wrote:
Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you the 
glue
records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us 
@’ for
all the addresses in the glue records.

e.g.
        dig +dnssec +norec http://internet-dns1.state.ma.us 
@http://146.243.122.17

Mark

> On 10 Feb 2021, at 14:50, sami's strat  wrote:
> 
> Thanks Mark.
> 
> However, the traceroute to the hostnamed failed for the same reason.  Please 
> note:
> 
> [root@myhost data]# dig http://internet-dns1.state.ma.us
>  
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> 
> http://internet-dns1.state.ma.us
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>  
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;http://internet-dns1.state.ma.us.     IN      A
>  
> ;; Query time: 1263 msec
> ;; SERVER: 192.168.33.12#53(192.168.33.12)
> ;; WHEN: Tue Feb 09 22:34:15 EST 2021
> ;; MSG SIZE  rcvd: 54
>  
> [root@myhost data]# dig http://internet-dns1.state.ma.us +trace
>  
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> 
> http://internet-dns1.state.ma.us +trace
> ;; global options: +cmd
> .                       516485  IN      NS      http://c.root-servers.net.
> .                       516485  IN      NS      http://e.root-servers.net.
> .                       516485  IN      NS      http://f.root-servers.net.
> .                       516485  IN      NS      http://l.root-servers.net.
> .                       516485  IN      NS      http://m.root-servers.net.
> .                       516485  IN      NS      http://d.root-servers.net.
> .                       516485  IN      NS      http://g.root-servers.net.
> .                       516485  IN      NS      http://k.root-servers.net.
> .                       516485  IN      NS      http://b.root-servers.net.
> .                       516485  IN      NS      http://h.root-servers.ne

Re: Filter out TSIG records from zone transfer

[Stuart@registry.godaddy]

I usually just GREP them out.

dig -k  axfr zone @remotehost | grep -v 'ANY[[:space:]]TSIG[[:space:]]'

Stuart

On 7/12/20, 1:32 am, "bind-users on behalf of Anand Buddhdev" 
 wrote:

Notice: This email is from an external sender.



Hi folks,

When I use "dig" to do a zone transfer, using TSIG, then the resulting
zone is interspersed with TSIG records. Some tools, such as
"dnssec-verify", don't like these records.

Is there any way to tell dig not to print these TSIG records? Currently,
I pass the zone through an awk script to filter out these records, but
it would be nice if I could tell dig itself to suppress them.

Regards,
Anand Buddhdev
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Key rollover for inline signing zones

[Stuart@registry.godaddy]

Manual steps?


  *   Generate keys (dnssec-keygen)
 *   Set appropriate Publish and Activation times with the arguments
  *   Set appropriate de-activation and removal times on existing keys 
(dnssec-settime)

BIND should do the rest. You can use rndc loadkeys  to hurry up the 
automation a little bit, but there’s really not much to it.

You might want to have a read through https://kb.isc.org/docs/aa-00822 for some 
more details on the concepts involved, and https://kb.isc.org/docs/aa-00711 for 
more inline-signing specific steps.

Stuart

From: bind-users  on behalf of rams 

Date: Wednesday, 28 October 2020 at 7:47 pm
To: bind-users 
Subject: Key rollover for inline signing zones

Notice: This email is from an external sender.


Hi,
Can anyone share the steps and commands for key rollover for inline signing 
zones in bind by manual/auto.

Regards,
Ramesh
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users