Re: RES_TRUSTAD, was Trying again on SERVFAIL
>> So ... I can't get the glibc behaviour to mesh with the standard >> on this particular point. > > It's set in RFC 6840: I stand corrected, thanks. - Håvard ___ 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
Can't use Bind DLZ through LDAPS SSL
Hi there, I really don't know If this is the correct place to ask about Bind DLZ, but I'm afraid that I could not have any responses from the BIND DLZ mail list and, since this seems to be an "official" plugin and it's compiled on the bind9 package from the SuSE15 SP2 repository I will try to ask it over here. I've deployed an OpenLDAP using the security options recommended by my cybersecurity team: - olcSecurity: ssf=256 - olcLocalSSF: 256 - olcRequires: authc - olcDisallow: bind_anon - olcTLSVerifyClient: try So essentially right now is required to use certificates and LDAPS in order to bind to the OpenLDAP server. Otherwise a Confidential error will appear since TLS SSL Handshake is not possible. Well, this is the expected behavior. All the software of the environment works flawlessly using the SSL Certificates through LDAPS SSL except Bind DLZ. I could not find the way to configure it to use SSL. The Bind DLZ used is the one compiled with the BIND 9.16.6 (Stable Release) from the SUSE 15 SP2 repository. Could anybody help me? Thank you so much. Regards. Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com P Please consider the environment before printing this e-mail. ___ 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.
Most people like yourself that do not care about OS purity often are not obligated (granted super broad generalization) to explain their changes to an Enterprise Change Management Board (ECMB or similar) for deviations from a "standard image". That is also 100% okay too. Those types of shops/sysadmins also typically don't have a buckets of cash sitting around either so you work with makes sense and use the resources available to get it done. The over-arching point is that the lowest common denominator for proper troubleshooting is that tcpdump is useful and it does not need to be sourced or installed. It is ready to go out of the box for nearly all situations that could potentially be encountered. Usually. Murphy's law of unintended consequences should always be account for. John -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of @lbutlr Sent: Thursday, February 11, 2021 6:18 PM To: bind-users Subject: Re: Bind 9.11 serving up false answers for a single domain. On 11 Feb 2021, at 16:38, John W. Blue via bind-users wrote: > I have found to tshark to be useful as well but the failing it has is that it > is generally not included in a unix OS distribution. Is bind? I mean, I have to install a bunch of stuff right off on a new bistro just to get a useable (for me) system. And if it's Linux I often have to UNinstall some things as well. I don't care about the purity of the distributions software set. -- Hey kids, shake it loose together the spotlight's hitting something That's been known to change the weather we'll kill the fatted calf tonight So stick around you're gonna hear electric music: Solid walls of sound ___ 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: Bind 9.11 serving up false answers for a single domain.
On 11 Feb 2021, at 16:38, John W. Blue via bind-users wrote: > I have found to tshark to be useful as well but the failing it has is that it > is generally not included in a unix OS distribution. Is bind? I mean, I have to install a bunch of stuff right off on a new bistro just to get a useable (for me) system. And if it's Linux I often have to UNinstall some things as well. I don't care about the purity of the distributions software set. -- Hey kids, shake it loose together the spotlight's hitting something That's been known to change the weather we'll kill the fatted calf tonight So stick around you're gonna hear electric music: Solid walls of sound ___ 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.
I have found to tshark to be useful as well but the failing it has is that it is generally not included in a unix OS distribution. Assuming anything referred to as "being in production" should also be following good change management protocols it makes sense to be fluent with tools that are readily accessible when a super fun session of all-of-sudden-troubleshooting breaks out. We recently had issues with a vendor that (I won't mention any names but it rhymes with proofpoint) where they insisted that the error we were having was on our side of the fence. They were basically unwilling to lift a finger to help. Color me shocked because I thought that how only Microsoft rolled. Packet captures proved that it was a load balancing code issue on their side and only then were they compelled to take action. Being able to correctly examine packets on the wire is a "must have" skillset to be an effective sysadmin. It can save the day or save your butt. @OP: very curious as to where you are at now in your troubleshooting. Status update? John -Original Message- From: Paul Kosinski [mailto:b...@iment.com] Sent: Wednesday, February 10, 2021 10:37 PM To: bind-users@lists.isc.org Cc: John W. Blue Subject: Re: Bind 9.11 serving up false answers for a single domain. 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 .. 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 ___ 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
RES_TRUSTAD, was Trying again on SERVFAIL
On Thu 11/Feb/2021 17:44:20 +0100 Havard Eidnes wrote: Yeah, by the time it lands on Debian's glibc we'll have grown a long long beard. I'm still missing RES_TRUSTAD... Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD before, so I found https://man7.org/linux/man-pages/man5/resolv.conf.5.html which under "trust-ad" contains this text: If the trust-ad option is active, the stub resolver sets the AD bit in outgoing DNS queries (to enable AD bit support), [...] It's similar to dig's man page: +[no]adflag Set [do not set] the AD (authentic data) bit in the query. This requests the server to return whether all of the answer and authority sections have all been validated as secure according to the security policy of the server. AD=1 indicates that all records have been validated as secure and the answer is not from a OPT-OUT range. AD=0 indicate that some part of the answer was insecure or not validated. This bit is set by default. I could not get that to rhyme with what I had perceived to be the semantics of the AD bit, so I looked up RFC 4035 where near the end of section 3 (just before 3.1), I find this text: The AD bit is controlled by name servers; a security-aware name server MUST ignore the setting of the AD bit in queries. That's the name server, not the resolver. So ... I can't get the glibc behaviour to mesh with the standard on this particular point. It's set in RFC 6840: 5.7. Setting the AD Bit on Queries The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. Best Ale -- ___ 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: Trying again on SERVFAIL
The internet isn’t always on and it isn’t only composed of big tech companies with lots of resources. like Google's gmail, which has had hours-long service outages from time to time? ;-)___ 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: Trying again on SERVFAIL
> Yeah, by the time it lands on Debian's glibc we'll have grown a long > long beard. I'm still missing RES_TRUSTAD... Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD before, so I found https://man7.org/linux/man-pages/man5/resolv.conf.5.html which under "trust-ad" contains this text: If the trust-ad option is active, the stub resolver sets the AD bit in outgoing DNS queries (to enable AD bit support), [...] I could not get that to rhyme with what I had perceived to be the semantics of the AD bit, so I looked up RFC 4035 where near the end of section 3 (just before 3.1), I find this text: The AD bit is controlled by name servers; a security-aware name server MUST ignore the setting of the AD bit in queries. So ... I can't get the glibc behaviour to mesh with the standard on this particular point. Regards, - Håvard ___ 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: Trying again on SERVFAIL
On Thu 11/Feb/2021 14:47:13 +0100 Ondřej Surý wrote: Mark is right. The internet isn’t always on and it isn’t only composed of big tech companies with lots of resources. The internet consists of lot small systems made by people like you and me and we don’t have infinite resources to keep everything always on. 100% agreed. And honestly I find your quote about Cargo Cult very offensive to all those normal people maintaining the rest of the internet infrastructure that isn’t the current -umvirate. I don't share that point of view. I cited it as evidence of a way of thinking. I find it somewhat green, happy-go-lucky, but not offensive. After all, if you limit the range to personal messages, it's a legitimate way to conceive email services. Best Ale -- ___ 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: Trying again on SERVFAIL
Mark is right. The internet isn’t always on and it isn’t only composed of big tech companies with lots of resources. The internet consists of lot small systems made by people like you and me and we don’t have infinite resources to keep everything always on. And honestly I find your quote about Cargo Cult very offensive to all those normal people maintaining the rest of the internet infrastructure that isn’t the current -umvirate. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 11. 2. 2021, at 14:13, Mark Andrews wrote: > > Machines still fall over. They take the same amount of time to fix now as > they did 30 years ago. > > You still have to diagnose the fault. You still have to get the replacement > part. You still have to potentially restore from backups. Sometimes you can > switch to a standby machine which makes things faster. > > I’ve seem day long outages in the last 7 days. They still happen. Personally > I was happy the emails queued. > -- > Mark Andrews > >> On 11 Feb 2021, at 23:26, Alessandro Vesely wrote: >> >> On Wed 10/Feb/2021 22:38:05 +0100 J Doe wrote: >>> Out of curiosity, what servers have you encountered that no longer use the >>> five day cutoff ? >> >> >> I didn't take note, but I read discussions on the topic. Users expect mail >> to be delivered almost instantly. The "warning, still trying" messages >> should come sometime in between. If it comes the next day, by various >> people's experience, it is unacceptably too late. If you reduce that to a >> few hours, the total max queue lifetime cannot remain five days. >> >> At mine, although I keep the default 5d, I cut queue time for specific >> messages, such as complaints or dmarc reports, to ten hours. >> >> Quoting from the web: >> >> Queue lifetimes over a day is just Cargo Cult system administration, and a >> holdover from when the internet was much less "always on". >> >> https://serverfault.com/questions/735269/is-it-a-good-idea-to-reduce-the-give-up-time-for-e-mail-delivery#answer-826351 >> >> >> Best >> Ale >> -- >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ___ >> 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 signature.asc Description: Message signed with OpenPGP ___ 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: Trying again on SERVFAIL
Machines still fall over. They take the same amount of time to fix now as they did 30 years ago. You still have to diagnose the fault. You still have to get the replacement part. You still have to potentially restore from backups. Sometimes you can switch to a standby machine which makes things faster. I’ve seem day long outages in the last 7 days. They still happen. Personally I was happy the emails queued. -- Mark Andrews > On 11 Feb 2021, at 23:26, Alessandro Vesely wrote: > > On Wed 10/Feb/2021 22:38:05 +0100 J Doe wrote: >> Out of curiosity, what servers have you encountered that no longer use the >> five day cutoff ? > > > I didn't take note, but I read discussions on the topic. Users expect mail > to be delivered almost instantly. The "warning, still trying" messages > should come sometime in between. If it comes the next day, by various > people's experience, it is unacceptably too late. If you reduce that to a > few hours, the total max queue lifetime cannot remain five days. > > At mine, although I keep the default 5d, I cut queue time for specific > messages, such as complaints or dmarc reports, to ten hours. > > Quoting from the web: > >Queue lifetimes over a day is just Cargo Cult system administration, and a >holdover from when the internet was much less "always on". > > https://serverfault.com/questions/735269/is-it-a-good-idea-to-reduce-the-give-up-time-for-e-mail-delivery#answer-826351 > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > ___ > 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: Trying again on SERVFAIL
On Wed 10/Feb/2021 22:38:05 +0100 J Doe wrote: Out of curiosity, what servers have you encountered that no longer use the five day cutoff ? I didn't take note, but I read discussions on the topic. Users expect mail to be delivered almost instantly. The "warning, still trying" messages should come sometime in between. If it comes the next day, by various people's experience, it is unacceptably too late. If you reduce that to a few hours, the total max queue lifetime cannot remain five days. At mine, although I keep the default 5d, I cut queue time for specific messages, such as complaints or dmarc reports, to ten hours. Quoting from the web: Queue lifetimes over a day is just Cargo Cult system administration, and a holdover from when the internet was much less "always on". https://serverfault.com/questions/735269/is-it-a-good-idea-to-reduce-the-give-up-time-for-e-mail-delivery#answer-826351 Best Ale -- ___ 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: Trying again on SERVFAIL
On Thu 11/Feb/2021 10:44:58 +0100 Havard Eidnes wrote: Still, being able to differentiate a local network congestion from a remote bad configuration would help. That's true. There's https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 which look promising, trying to make it possible to distinguish between the various reasons a recursor might choose to return a SERVFAIL response. It uses an EDNS option to communicate the additional information. Commendable effort! As for its implementation status in general or in BIND in particular I'll admit that I don't know off-hand. Yeah, by the time it lands on Debian's glibc we'll have grown a long long beard. I'm still missing RES_TRUSTAD... Best Ale -- ___ 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: Trying again on SERVFAIL
> Still, being able to differentiate a local network congestion from a > remote bad configuration would help. That's true. There's https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 which look promising, trying to make it possible to distinguish between the various reasons a recursor might choose to return a SERVFAIL response. It uses an EDNS option to communicate the additional information. As for its implementation status in general or in BIND in particular I'll admit that I don't know off-hand. Regards, - Håvard ___ 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)
Thanks! That was the response I was looking for. Much appreciated! -- Ondřej Surý (He/Him) ond...@isc.org > On 11. 2. 2021, at 9:03, stuart@registry.godaddy wrote: > > 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 > > > signature.asc Description: Message signed with OpenPGP ___ 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)
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)
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
