Re: filter-a and dns64 in a ipv6-only network

[Eric Germann via bind-users]

> On Jan 31, 2023, at 15:27, Thomas Schäfer  wrote:
> 
> Am Dienstag, 31. Januar 2023, 20:03:42 CET schrieb Marco:
> 
>> 
>> Why would it make sense to block them?
> 
> Avoiding wrong decisions by "happy eyeballs" - probably the same rare reasons
> why isc introduced the  filter yeas ago - in theory there is no reason to
> block  nor A. But blocking A depending on the existence of   makes no
> sense at all.
> (as bind at moment is doing)


I’ve found one edge case where blocking  records fixes something in order 
to force it to A addresses.

Netflix

I use a Hurricane Electric tunnel for my IPv6.  Works like a charm for every 
other site I use.  But Netflix rejects connections because it thinks it’s on a 
VPN.  So, filtering the quad A makes it appear it isn’t IPv6 enabled, so it 
connects over 4.  Works like a champ.

Eric



signature.asc
Description: Message signed with OpenPGP
-- 
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: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Eric Germann via bind-users]

On Dec 29, 2022, at 16:34, Timothe Litt  wrote:



Yup, Eric's case was a classic example.  He tried to do the right thing, put in 
the wrong record, and the system didn't produce the expected results.  To his 
credit, he persisted.  Most people don't.  A while ago there was a study 
(cloudflare/APNIC 
) 
that showed that about only about 40% of people who enabled DNSSEC for their 
accounts successfully served DS records in their registry.



The really annoying part is it isn’t obvious that they want the public key and 
not the result of dnssec-dsfromkey; they do it themselves.  The annoying part 
is they throw an error if the key isn’t valid Base64 (think spaces or 
newlines), but gladly accept the DS output from dnssec-dsfromkey.  Somehow or 
another they are getting the key tag from the incorrect DS  record, because 
they encode again the already encoded string.

I looked in the docs for boto3 (the official API for AWS) and there appears no 
way to add a public key so you can’t do it programmatically.

I’ll have to pass that on to my AWS contacts.  Doubt they’ll do anything but it 
is worth throwing it over the fence.

Again, thanks for all the help!

Eric



signature.asc
Description: Message signed with OpenPGP
-- 
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: Funky Key Tag in AWS Route53 (2)

[Eric Germann via bind-users]

I understand all the tools and output.  The error I was trying to find is why 
they disagreed and checking all the points along the way.  Thanks for your 
scripts.

Anyways, for GoogleFu, I got it fixed and it works correctly now thanks to 
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2

For entering the DS record in to Route53, you enter the whole public key in 
Base64 without spaces or newlines, not the hash of the key like the registrars 
I’ve used for other domains.

What is annoying is it accepts the hash as perfectly valid and gets the  DS 
record number as the wrong ID.

Thanks to all who helped!

Eric


> On Dec 29, 2022, at 10:06, Timothe Litt  wrote:
> 
> 
>> That’s why I wanted to decode the DS record to see if it’s encoding it as 
>> 32686 or 22755
> 
> As I said, no decoding required.  Just look at the DS record.  The keytag is 
> immediately after "DS" in plain, unencoded text.
> 
> If the question is how to verify the keytag from the DNSKEY it references, 
> I've shown you two different tools that produce the same result.
> 
> If you use the same input file, you get the same answer from ISC and 
> Net::DNS::SEC.
> 
> cat >tmp.key
> 
> ericgermann.photography. DNSKEY 257 3 8 
> AwEAAatPHgdYxFA74X+17xAMmZNn+I6XVzodbnA/m4M6vV+axYh+PTNt 
> xrZSQ4PXEcJkNXF5OR1UPfPWea/gGIuYUbjMaa2H7fd+TXqc+C44U/2O 
> vbZqefSUXl1QzqyxPyG7xZuAgTApFt+PuK9CrQtP7IV9qu34cXAXLGF1 
> SgrhBi843sTESw8nBAv1MDLMBCDEULVOSghqqxdJQ57yGOdsgYFdt6kL 
> UNA1zntZV49dDWHGttZWwhEnnMuNz+e6bRroETOIhtzxLn4HOievnZmV 
> 4rqzh5Zku/06QMNiUWwePW07RIGVVzUszU0LaAgBh/m111x5UiYfup2N egWHPunS1IM=
> 
> dnssec-dsfromkey -2 tmp
> ericgermann.photography. IN DS 32686 8 2 
> A17DF360A9E0CB485BD396A839119441C5FF62A9C9E46D586EBDD1D084E2E36B
> 
> That's the same answer as Net::DNS::SEC.  Two different tools from reputable 
> sources, same answer.
> 
> None of the installed keys have 22755.  DNSvis does show a DS record 
> installed with 22755 (and no matching key).  So AWS is installing that DS 
> from whatever input you provide it.
> 
> That leaves:
> 
> Different input to AWS vs. the local tools
> perhaps you have a file with a different DNSKEY that you are uploading to 
> AWS.  I've been known to accidentally overwrite, rename, or confuse files.  
> (Not often, but it happens.)
> have you verified that the contents of the file that you are using matches 
> what's in the DNS?
> Does AWS have an option to use a DNSKEY from your zone?  That would avoid the 
> manual step.
> If you're copy/pasting the DNSKEY file into AWS, corruption in the process 
> (buffer overruns?)
> It's not inconceivable that AWS has a bug, but someone should have hit one 
> like this before you
> Before blaming AWS, I'd be very sure that the same key is being input.  If it 
> is, they have a bug
> 
> You might also consider using a different key experimentally, on the off 
> chance that a wrong keytag bug is data-dependent.
> 
> But the most likely scenario is that somehow AWS is generating a DS for a 
> different key.
> 
> I don't use AWS, so that's as far as I can go.
> 
> Good luck.
> 
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
> On 29-Dec-22 09:28, Eric Germann wrote:
>> Yeah, that’s the problem I’m trying to solve.  I run the key thru 
>> dnssec-dsfromkey and get 32686, When I put the key in to Route53, I get 
>> 22755 from the decoded DS record in the console for Route53.
>> 
>> That’s why I wanted to decode the DS record to see if it’s encoding it as 
>> 32686 or 22755
>> 
>> 
>>> On Dec 29, 2022, at 09:17, Timothe Litt  
>>>  wrote:
>>> 
>>> On 28-Dec-22 19:40, Eric Germann wrote:
 My question is
 
 Is there any way to decode the DS record and see what key tag is actually 
 encoded in it?  If it’s 32686 it’s an issue with Route53.  If it’s 22755 
 it’s an issue with dnssec-dsfromkey.
 
 If anyone wants the DNSKEY for algorithm 8, ping me off list and I will 
 share it with you in a private email.
 
 Thoughts?
 
>>> And because it's trivial, here are the keytags for all your keys and DS 
>>> records and how to get them.  Note that you have DNSKEY 32686: installed in 
>>> the DNS, and that the installed DS is 22755.
>>> 
>>> Can't say how it got that way, but that's what is there.  (Manual processes 
>>> are error-prone.  That getting registrars to adopt CDS/CDNSKEY - RFC7344 - 
>>> has been so slow is unfortunate.)  It's rarely the tools.
>>> 
>>>  perl  -MNet::DNS::SEC -e'@keys = split /\n/, qx(dig +cdflag +short 
>>> ericgermann.photography DNSKEY); print "$_ => 
>>> ",Net::DNS::RR->new("ericgermann.photography. DNSKEY $_")->keytag,"\n" 
>>> foreach (@keys);'
>>> 257 3 8 AwEAAatPHgdYxFA74X+17xAMmZNn+I6XVzodbnA/m4M6vV+axYh+PTNt 
>>> xrZSQ4PXEcJkNXF5OR1UPfPWea/gGIuYUbjMaa2H7fd+TXqc+C44U/2O 
>>> vbZqefSUXl1QzqyxPyG7

Re: Funky Key Tag in AWS Route53 (2)

[Eric Germann via bind-users]

Yeah, that’s the problem I’m trying to solve.  I run the key thru 
dnssec-dsfromkey and get 32686, When I put the key in to Route53, I get 22755 
from the decoded DS record in the console for Route53.

That’s why I wanted to decode the DS record to see if it’s encoding it as 32686 
or 22755


> On Dec 29, 2022, at 09:17, Timothe Litt  wrote:
> 
> On 28-Dec-22 19:40, Eric Germann wrote:
>> My question is
>> 
>> Is there any way to decode the DS record and see what key tag is actually 
>> encoded in it?  If it’s 32686 it’s an issue with Route53.  If it’s 22755 
>> it’s an issue with dnssec-dsfromkey.
>> 
>> If anyone wants the DNSKEY for algorithm 8, ping me off list and I will 
>> share it with you in a private email.
>> 
>> Thoughts?
>> 
> And because it's trivial, here are the keytags for all your keys and DS 
> records and how to get them.  Note that you have DNSKEY 32686: installed in 
> the DNS, and that the installed DS is 22755.
> 
> Can't say how it got that way, but that's what is there.  (Manual processes 
> are error-prone.  That getting registrars to adopt CDS/CDNSKEY - RFC7344 - 
> has been so slow is unfortunate.)  It's rarely the tools.
> 
>  perl  -MNet::DNS::SEC -e'@keys = split /\n/, qx(dig +cdflag +short 
> ericgermann.photography DNSKEY); print "$_ => 
> ",Net::DNS::RR->new("ericgermann.photography. DNSKEY $_")->keytag,"\n" 
> foreach (@keys);'
> 257 3 8 AwEAAatPHgdYxFA74X+17xAMmZNn+I6XVzodbnA/m4M6vV+axYh+PTNt 
> xrZSQ4PXEcJkNXF5OR1UPfPWea/gGIuYUbjMaa2H7fd+TXqc+C44U/2O 
> vbZqefSUXl1QzqyxPyG7xZuAgTApFt+PuK9CrQtP7IV9qu34cXAXLGF1 
> SgrhBi843sTESw8nBAv1MDLMBCDEULVOSghqqxdJQ57yGOdsgYFdt6kL 
> UNA1zntZV49dDWHGttZWwhEnnMuNz+e6bRroETOIhtzxLn4HOievnZmV 
> 4rqzh5Zku/06QMNiUWwePW07RIGVVzUszU0LaAgBh/m111x5UiYfup2N egWHPunS1IM= => 32686
> 256 3 8 AwEAAaD+/5eN/zIqYhG/CXXastruIQEBBuD2Y2Yinx+IqWvInKc5Kb6K 
> AWvUWECjn0Q7Lrt1s759/04SZXm2M4GwuKBzY+Ern2ukWi0hQmUBqoET 
> VSrFhu75FJpi0+8wJZhx5UVPg7NTriYXC29rSTBt/OCr/Ot+utf2P9G2 
> hr/BXQqcwausick9Gu9zZtzB0072IEM6okZW1rDwlAwmlDjicJgbAnRt 
> qgpWX21CgRG/G8Jjz4pGSP1rt54ilxVbCL8KR3huRaJGb6lnnJnQJckL 
> oN2+rGaps1bLYC79fgdL5Y/fzR43J+te7RBo4AJXFhW9n1WL6KOKbprE pbl7yiINzTU= => 43126
> 256 3 13 bX62WTOQmhTaqnQprecHwUjDzBGAQbF0kqywkNzE1yBTrmP/zBNhvtp+ 
> H9iYf1OOcfyDo6iE1XXUCNKHKZFHkg== => 36584
> 256 3 15 9SM6gMjImcK0sKPvIlEr9ZNKxsqmSL9zO7P9kZTH8XQ= => 48248
> 257 3 15 A8W3oD5oGEkHjOTfCmPbEBzHHTILksfywXvjQ5r9/dA= => 13075
> 257 3 13 DBT06AacWTT1cD//OgwSSNRT9UTZdAgbJOnU/sWcFYhJ+x9SHvpfZGF6 
> tkGehWujsuYtwLf0aKt2b1mjQUk/BA== => 49677
> 
> perl  -MNet::DNS::SEC -e'@keys = split /\n/, qx(dig +cdflag +short 
> ericgermann.photography DS); print "$_ => 
> ",Net::DNS::RR->new("ericgermann.photography. DS $_")->keytag,"\n" foreach 
> (@keys);'
> 22755 8 2 2E81A125523957ED2C3076B4E58BE159027F659D74E184E2F0B81D92 2D1E7FA9 
> => 22755
> 
> You can, of course, use data from your files instead of dig.  Works for both 
> DS and DNSKEY
> 
>  perl -MNet::DNS -MNet::DNS::SEC -e' print 
> Net::DNS::RR->new("ericgermann.photography. DS 22755 8 2 
> 2E81A1255ED2C3076B4E58BE159027F659D74E184E2F0B81D92 2D1E7FA9")->keytag,"\n"'
> 
> 
> 
> Enjoy.
> 
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
-- 
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

Funky Key Tag in AWS Route53

[Eric Germann via bind-users]

I’m running bind 9.18.10 and having a hell of a time with AWS Route53 and 
DNSSEC.

I’m testing dnssec-policy and have algorithms 8, 13, and 15 set.  On the test 
domain I’m using, I wiped the old keys, deleted the DS records in the parent 
zone and basically started from scratch.

I started named and it created new .key/.private files in the key directory.  
My KSK is Kericgermann.photography.+008+32686.key and I run dnssec-dsfromkey 
and get a DS record.  I cut and paste that record in to Route53 DNSSEC config 
and it decodes the key tag as 22755 instead of 32686.

I get a DNSviz diagram that looks like this 
https://dnsviz.net/d/ericgermann.photography/dnssec/

In the diagram, .photography is looking for a key tag of 22755 instead of the 
correct 32686 for algorithm 8.

My question is

Is there any way to decode the DS record and see what key tag is actually 
encoded in it?  If it’s 32686 it’s an issue with Route53.  If it’s 22755 it’s 
an issue with dnssec-dsfromkey.

If anyone wants the DNSKEY for algorithm 8, ping me off list and I will share 
it with you in a private email.

Thoughts?


--
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Medium: https://ekgermann.medium.com 
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1









signature.asc
Description: Message signed with OpenPGP
-- 
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 dir massive

[Eric Germann via bind-users]

> On Dec 22, 2022, at 09:32, Matthijs Mekking  wrote:
> 
> 


> I hope you have read our KB article on dnssec-policy before migrating:
> 
>  https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy
> 
> It should list the main pitfalls to save you a lot of hassle (I suspect you 
> started algorithm rollover immediately when changing to dnssec-policy 
> default).
> 
> If there are any things we should add, I am happy to receive your suggestions.

Are there any examples from ISC on how to handle multiple algorithms in the 
dnssec-policy stanza?  I’m running 8 and 13 both as an experiment

Eric

-- 
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: Odd problem with DoH and DoT

[Eric Germann via bind-users]

Never mind.  Rebooting the box resolved it.  I’m still curious how it got 
crossed

--
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann 
<https://www.linkedin.com/in/ericgermann>
Medium: https://ekgermann.medium.com <https://ekgermann.medium.com/> 
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







> On Oct 6, 2022, at 19:02, Eric Germann via bind-users 
>  wrote:
> 
> I’m having a really weird issue with 9.18.3
> 
> When I connect with OpenSSL to this particular server, I get two different 
> server certs
> 
> Here is my requisite configs
> 
>listen-on   port 53 { any; };
>listen-on   port 443 tls local-tls http local-http-server 
> { any; };
>listen-on   port 853 tls local-tls { any; };
>listen-on-v6port 53 { any; };
>listen-on-v6port 443 tls local-tls http local-http-server 
> { any; };
>listen-on-v6port 853 tls local-tls { any; };
>http-port   80;
>https-port  443;
> };
> 
> tls local-tls {
>key-file  "/etc/namedb/keys/privkey.pem";
>cert-file "/etc/namedb/keys/fullchain.pem";
> };
> 
> http local-http-server {
>endpoints { "/dns-query";  };
> };
> 
> my last line of the cert in fullchain.pem for the correct server cert is
> 
> "+sWJ8Oluyktfz7I5MSsXwIqCMK/4qG/S4hf04FUk"
> 
> 
> When I connect to port 443 for DoH, I get a server cert that ends in “FUk”
> 
> When I connect to port 853 for DoT, I get a server cert that ends in 
> “HhQraavJaViojiiFyfcKONWCPVuQozJDWoICan7i”.  The issue is when I execute
> 
> kdig -d @ns05x.semperen.com +tls-sni=ns05x.semperen.com 
> +tls-host=ns05x.semperen.com semperen.com mx
> 
> I get back 
> 
> ;; DEBUG: Querying for owner(semperen.com.), class(1), type(15), 
> server(ns05x.semperen.com), port(853), protocol(TCP)
> ;; DEBUG: TLS, imported 127 system certificates
> ;; DEBUG: TLS, received certificate hierarchy:
> ;; DEBUG:  #1, CN=ns05x.semperen.com
> ;; DEBUG:  SHA-256 PIN: WLEeS4l9ObJUnZ1X055NrxlYkzaep5Ynig7KA8GnuqE=
> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=R3
> ;; DEBUG:  SHA-256 PIN: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
> ;; DEBUG:  #3, C=US,O=Internet Security Research Group,CN=ISRG Root X1
> ;; DEBUG:  SHA-256 PIN: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
> ;; DEBUG: TLS, skipping certificate PIN check
> ;; DEBUG: TLS, The certificate is NOT trusted. The certificate chain uses 
> expired certificate. 
> ;; WARNING: TLS, handshake failed (Error in the certificate.)
> ;; DEBUG: TLS, received certificate hierarchy:
> ;; DEBUG:  #1, CN=ns05x.semperen.com
> ;; DEBUG:  SHA-256 PIN: WLEeS4l9ObJUnZ1X055NrxlYkzaep5Ynig7KA8GnuqE=
> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=R3
> ;; DEBUG:  SHA-256 PIN: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
> ;; DEBUG:  #3, C=US,O=Internet Security Research Group,CN=ISRG Root X1
> ;; DEBUG:  SHA-256 PIN: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
> ;; DEBUG: TLS, skipping certificate PIN check
> ;; DEBUG: TLS, The certificate is NOT trusted. The certificate chain uses 
> expired certificate. 
> ;; WARNING: TLS, handshake failed (Error in the certificate.)
> ;; ERROR: failed to query server ns05x.semperen.com@853(TCP)
> 
> 
> Which says the cert is expired.  When checking the cert with OpenSSL that is 
> returned, the start and end dates are the same, Jul 4 2022.
> 
> In the LetsEncrypt dir, in “archive” dorectory fullchain7.pem is the current 
> cert and the symbolic link in “live” is linked to this.  However, that tail 
> end of the incorrect server cert is contained in "fullchain5.pem”, and it is 
> expired.  I relinked the files to make sure it wasn’t a file system issue.  
> How is it picking up the wrong full chain when I point it to a dir with only 
> the links to chain7?
> 
> Querying ns04x.semperen.com returns the same cert on both ports.
> 
> Thanks for any pointers
> 
> --
> Eric Germann
> ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
> LinkedIn: https://www.linkedin.com/in/ericgermann
> Medium: https://ekgermann.medium.com 
> Twitter: @ekgermann
> Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712
> 
> GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1
> 
> 
> 
> 
> 
> 
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> I

Odd problem with DoH and DoT

[Eric Germann via bind-users]

I’m having a really weird issue with 9.18.3

When I connect with OpenSSL to this particular server, I get two different 
server certs

Here is my requisite configs

listen-on   port 53 { any; };
listen-on   port 443 tls local-tls http local-http-server { 
any; };
listen-on   port 853 tls local-tls { any; };
listen-on-v6port 53 { any; };
listen-on-v6port 443 tls local-tls http local-http-server { 
any; };
listen-on-v6port 853 tls local-tls { any; };
http-port   80;
https-port  443;
};

tls local-tls {
key-file  "/etc/namedb/keys/privkey.pem";
cert-file "/etc/namedb/keys/fullchain.pem";
};

http local-http-server {
endpoints { "/dns-query";  };
};

my last line of the cert in fullchain.pem for the correct server cert is

"+sWJ8Oluyktfz7I5MSsXwIqCMK/4qG/S4hf04FUk"


When I connect to port 443 for DoH, I get a server cert that ends in “FUk”

When I connect to port 853 for DoT, I get a server cert that ends in 
“HhQraavJaViojiiFyfcKONWCPVuQozJDWoICan7i”.  The issue is when I execute

kdig -d @ns05x.semperen.com +tls-sni=ns05x.semperen.com 
+tls-host=ns05x.semperen.com semperen.com mx

I get back 

;; DEBUG: Querying for owner(semperen.com.), class(1), type(15), 
server(ns05x.semperen.com), port(853), protocol(TCP)
;; DEBUG: TLS, imported 127 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=ns05x.semperen.com
;; DEBUG:  SHA-256 PIN: WLEeS4l9ObJUnZ1X055NrxlYkzaep5Ynig7KA8GnuqE=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=R3
;; DEBUG:  SHA-256 PIN: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
;; DEBUG:  #3, C=US,O=Internet Security Research Group,CN=ISRG Root X1
;; DEBUG:  SHA-256 PIN: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The certificate chain uses 
expired certificate. 
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=ns05x.semperen.com
;; DEBUG:  SHA-256 PIN: WLEeS4l9ObJUnZ1X055NrxlYkzaep5Ynig7KA8GnuqE=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=R3
;; DEBUG:  SHA-256 PIN: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
;; DEBUG:  #3, C=US,O=Internet Security Research Group,CN=ISRG Root X1
;; DEBUG:  SHA-256 PIN: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The certificate chain uses 
expired certificate. 
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server ns05x.semperen.com@853(TCP)


Which says the cert is expired.  When checking the cert with OpenSSL that is 
returned, the start and end dates are the same, Jul 4 2022.

In the LetsEncrypt dir, in “archive” dorectory fullchain7.pem is the current 
cert and the symbolic link in “live” is linked to this.  However, that tail end 
of the incorrect server cert is contained in "fullchain5.pem”, and it is 
expired.  I relinked the files to make sure it wasn’t a file system issue.  How 
is it picking up the wrong full chain when I point it to a dir with only the 
links to chain7?

Querying ns04x.semperen.com returns the same cert on both ports.

Thanks for any pointers

--
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Medium: https://ekgermann.medium.com 
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







-- 
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: Adding a new domain with DNSSEC

[Eric Germann via bind-users]

Are you missing a left paren before "1-16”?


Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann 

Medium: https://ekgermann.medium.com  
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







> On Apr 10, 2022, at 4:40 AM, @lbutlr  wrote:
> 
> I have an several domains setup in bind, all with DNSSEC implemented, and am 
> trying to add a new domain, and seem to have missed a step.
> 
> 
> # dnssec-keygen -a 13 example,com
> # dnssec-keygen -f KSK -a 13 example,com
> 
> Add $INLCUDE to the zone file for each of these 4 keys.
> 
> # dnssec-signzone -3 $(head -c 1000 /dev/random | shasum | cut -b 1-16) -o 
> example.com -t example.com
> 
> dnssec-signzone: warning: keys/Kexample.com.+013+55923.private:1: unknown RR 
> type 'v1.3'
> dnssec-signzone: fatal: failed loading zone from 'example.com': unknown 
> class/type
> 
> 
> -- 
> "Are you pondering what I'm pondering?"
> "I think so, Brain! But ruby-studded stockingswould be mighty
>   uncomfortable wouldn't they?"
> 
> -- 
> 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

-- 
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: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?

[Eric Germann via bind-users]

Why not as a stopgap to protect your human rights, use you phone as a hotspot?  
Cheaper than suing everyone

Eric

> On Jan 8, 2022, at 11:17, Stephane Bortzmeyer  wrote:
> 
> On Sat, Jan 08, 2022 at 04:55:24PM +0100,
> Stephane Bortzmeyer  wrote 
> a message of 52 lines which said:
> 
>> This domain name seems OK for me but I notice that a fair number of
>> RIPE Atlas probes in Ireland return a fake NXDOMAIN for this name:
> 
> On Twitter, an Irish DNS expert said that it happened
> before. Apparently, many ISP use a blacklist without thinking and this
> blacklist include legitimate domain names.
> ___
> 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

Reloading new certs for DNS over HTTPS

[Eric Germann via bind-users]

I’ve implemented DNS over HTTPS on two of my servers to get some experience.  
I’m using LetsEncrypt for the cert issuer.

I ran in to an issue where it appears named only reads them on init.  The cert 
expired and certbot faithfully renewed it, but was using the old cert it read 
at initialization.

My question is if a “rndc reconfig” will read the new cert when it reloads the 
config or do I have to stop and start named to get it to pick it up?

Thanks

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







___
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: Contents of bind-users digest...

[Eric Germann via bind-users]

Or “make dig”

> On Jul 6, 2021, at 11:47, Paul Kosinski via bind-users 
>  wrote:
> 
> On Tue, 6 Jul 2021 12:44:15 +
> "MURTARI, JOHN"  wrote:
> 
>> Folks, let me add my desire for a quick download dig supporting DoH.  It 
>> could really help with some testing, some ready stuff for Ubuntu 18/20,  
>> Redhat/CentOS, could make a lot of people happy.   Maybe the libs included 
>> and we set the LD_LIBRARY_PATH, or a 'static' link?
>> 
>> 
>> It only takes a 'few minutes' more -- once you spend a few hours getting the 
>> whole environment setup.  some don't build it all the time.
>> 
>> 
>> I'll give ISC Five Stars on Google! 😃
>> 
>> 
>>>> On 6 Jul 2021, at 05:56, Eric Germann via bind-users 
>>>>  wrote:
>>> 
>>> Has ISC given any thought to releasing dig as a separate source package?
>>> 
>>> It?s good for testing DoH, but you need to build the entire bind package to 
>>> get it.  It would be useful for support analysts without the overhead of 
>>> compiling all of bind to get it  
>> 
>> Really, it a couple of extra megabytes of disk space and a couple of extra 
>> minutes of compile
>> time.  Dig is not a stand alone component.  It depends on libisc, libdns, 
>> libisccfg, libirs, and
>> libbind9.  Thats most of the libraries we build.  It makes no sense to have 
>> a seperate source
>> package for dig.
> 
> 
> It isn't mainly the disk space and extra build time, it's the complexity. 
> Somebody who only wants 'dig' would have to figure out how to isolate it from 
> the result of the build. This would be especially troublesome after doing a 
> "make install" (which I suspect is necessary to get the 'dig' executable 
> properly set up) as there would be a whole lot of undesired stuff installed. 
> Perhaps adding a "install-dig-only" option to the make file would be possible 
> and not a lot of work?
> ___
> 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

dig standalone source?

[Eric Germann via bind-users]

Has ISC given any thought to releasing dig as a separate source package?

It’s good for testing DoH, but you need to build the entire bind package to get 
it.  It would be useful for support analysts without the overhead of compiling 
all of bind to get it

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







___
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: Compiling bind 9.17.15 with alternate OpenSSL library

[Eric Germann via bind-users]

Bummer.

Thanks for the quick turnaround though!

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







> On Jul 5, 2021, at 1:07 PM, Ondřej Surý  wrote:
> 
> Oh, you are right. That will get only used when pkg-config based method 
> doesn’t work. We probably should remove that as openssl.pc is now widely 
> available.
> 
> Ondřej
> --
> Ondřej Surý — ISC (He/Him)
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 5. 7. 2021, at 18:57, Eric Germann  wrote:
>> 
>> I’m confused
>> 
>> ./configure --help | grep openssl
>> 
>>   --with-openssl=DIR  root of the OpenSSL directory
>> 
>> ---
>> Eric Germann
>> ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
>> LinkedIn: https://www.linkedin.com/in/ericgermann 
>> <https://www.linkedin.com/in/ericgermann>
>> Twitter: @ekgermann
>> Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712
>> 
>> GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jul 5, 2021, at 12:55 PM, Ondřej Surý >> <mailto:ond...@isc.org>> wrote:
>>> 
>>> Eric,
>>> 
>>> configure uses pkg-config to detect OpenSSL version thus you need to point 
>>> pkg-config to the right directory.
>>> 
>>> There’s no such option to configure.
>>> 
>>> Ondřej
>>> --
>>> Ondřej Surý — ISC (He/Him)
>>> 
>>> My working hours and your working hours may be different. Please do not 
>>> feel obligated to reply outside your normal working hours.
>>> 
>>>> On 5. 7. 2021, at 18:24, Eric Germann via bind-users 
>>>> mailto:bind-users@lists.isc.org>> wrote:
>>>> 
>>>> I’m in the process of building a custom version of bind with DoH and 
>>>> would also like to add DNSSEC algorithm 15 for experimental purposes
>>>> 
>>>> DoH works just fine on the servers I have configured.
>>>> 
>>>> My “configure" command is
>>>> 
>>>>   ./configure --with-openssl=../openssl-1.1.1k --with-libxml2 
>>>> --with-json-c --disable-dnstap --enable-fixed-rrset --enable-querytrace 
>>>> --sysconfdir=/etc/namedb
>>>> 
>>>> When I override the SSL library, it doesn’t pick it up.  It uses the 
>>>> system library of 1.0.2k-fips from the system (Centos 7 
>>>> 10.0-1160.25.1.el7.x86_64 #1 SMP Wed Apr 28 21:49:45 UTC 2021 x86_64 
>>>> x86_64 x86_64 GNU/Linux)
>>>> 
>>>> I know when I build nginx, I can override the SSL library by pointing to 
>>>> the OpenSSL directory and it shows and functions with the correct library 
>>>> (1.1.1k).
>>>> 
>>>> I’ve built OpenSSL in the directory spec’d in the config line, but haven’t 
>>>> done a “make install” because it will trash the system.
>>>> 
>>>> Is there anyway to build against 1.1.1k without doing a “make install” on 
>>>> the newer OpenSSL library?
>>>> 
>>>> Thanks
>>>> 
>>>> ---
>>>> Eric Germann
>>>> ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
>>>> LinkedIn: https://www.linkedin.com/in/ericgermann 
>>>> <https://www.linkedin.com/in/ericgermann>
>>>> Twitter: @ekgermann
>>>> Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712
>>>> 
>>>> GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users 
>>>> <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/ 
>>>> <https://www.isc.org/contact/> for more information.
>>>> 
>>>> 
>>>> bind-users mailing list
>>>> bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
>>>> https://lists.isc.org/mailman/listinfo/bind-users 
>>>> <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: Compiling bind 9.17.15 with alternate OpenSSL library

[Eric Germann via bind-users]

I’m confused

./configure --help | grep openssl

  --with-openssl=DIR  root of the OpenSSL directory

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







> On Jul 5, 2021, at 12:55 PM, Ondřej Surý  wrote:
> 
> Eric,
> 
> configure uses pkg-config to detect OpenSSL version thus you need to point 
> pkg-config to the right directory.
> 
> There’s no such option to configure.
> 
> Ondřej
> --
> Ondřej Surý — ISC (He/Him)
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 5. 7. 2021, at 18:24, Eric Germann via bind-users 
>>  wrote:
>> 
>> I’m in the process of building a custom version of bind with DoH and would 
>> also like to add DNSSEC algorithm 15 for experimental purposes
>> 
>> DoH works just fine on the servers I have configured.
>> 
>> My “configure" command is
>> 
>>   ./configure --with-openssl=../openssl-1.1.1k --with-libxml2 --with-json-c 
>> --disable-dnstap --enable-fixed-rrset --enable-querytrace 
>> --sysconfdir=/etc/namedb
>> 
>> When I override the SSL library, it doesn’t pick it up.  It uses the system 
>> library of 1.0.2k-fips from the system (Centos 7 10.0-1160.25.1.el7.x86_64 
>> #1 SMP Wed Apr 28 21:49:45 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux)
>> 
>> I know when I build nginx, I can override the SSL library by pointing to the 
>> OpenSSL directory and it shows and functions with the correct library 
>> (1.1.1k).
>> 
>> I’ve built OpenSSL in the directory spec’d in the config line, but haven’t 
>> done a “make install” because it will trash the system.
>> 
>> Is there anyway to build against 1.1.1k without doing a “make install” on 
>> the newer OpenSSL library?
>> 
>> Thanks
>> 
>> ---
>> Eric Germann
>> ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
>> LinkedIn: https://www.linkedin.com/in/ericgermann 
>> <https://www.linkedin.com/in/ericgermann>
>> Twitter: @ekgermann
>> Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712
>> 
>> GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

Compiling bind 9.17.15 with alternate OpenSSL library

[Eric Germann via bind-users]

I’m in the process of building a custom version of bind with DoH and would also 
like to add DNSSEC algorithm 15 for experimental purposes

DoH works just fine on the servers I have configured.

My “configure" command is

  ./configure --with-openssl=../openssl-1.1.1k --with-libxml2 --with-json-c 
--disable-dnstap --enable-fixed-rrset --enable-querytrace 
--sysconfdir=/etc/namedb

When I override the SSL library, it doesn’t pick it up.  It uses the system 
library of 1.0.2k-fips from the system (Centos 7 10.0-1160.25.1.el7.x86_64 #1 
SMP Wed Apr 28 21:49:45 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux)

I know when I build nginx, I can override the SSL library by pointing to the 
OpenSSL directory and it shows and functions with the correct library (1.1.1k).

I’ve built OpenSSL in the directory spec’d in the config line, but haven’t done 
a “make install” because it will trash the system.

Is there anyway to build against 1.1.1k without doing a “make install” on the 
newer OpenSSL library?

Thanks

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1









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: Odd A record in our hosts zone file

[Eric Germann via bind-users]

Time to live in the cache. Short time to live is useful when you need to change 
the A record to swing one host to another. 

> On Jun 25, 2021, at 12:56, Bruce Johnson  wrote:
> 
> I ran across these A records in one of our zone files:
> 
> ;EXCHANGE STUFF
> mail1m  IN  A   xxx.xxx.xxx.52; dhbex1
> mail1m  IN  A   xxx.xxx.xxx.54; dhbex2
> 
> I can see that this is a cheap load-balancing for our exchange OWA servers, 
> but what is the ‘1m’ notation? I haven’t been able to find that in my 
> searching of the manual.
> 
> (We’re adding new servers and I need to make sure our DNS is properly set for 
> them.)
> 
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs
> 
> ___
> 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: 9.11 to 9.16: need directions

[Eric Germann via bind-users]

bind doesn’t support @ signs for the email contact.  It would be 
root.rn6.xyz.local

Line 15, missing the class (IN)?  

DeadStick   IN A 192.168.255.156
> 
> INTXT"310702541c5622d0e6001136bd71a6578b"

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







> On Jun 12, 2021, at 8:33 PM, ToddAndMargo via bind-users 
>  wrote:
> 
> On 6/12/21 5:30 PM, ToddAndMargo via bind-users wrote:
>> Hi All,
>> I just upgraded from Fedora 33 to Fedora 34.
>> Bind was updated from 9.11 to 9.16 in Fedora 34.
>> It completely broke my Fedora 33 configuration.
>> Would someone please point me to the directions
>> as to how to migrate from 9.11 to 9.16?
>> Many thanks,
>> -T
> 
> Some of my error messages:
> 
> # named-checkzone -t /var/named/chroot/var/named/slaves xyz xyz.hosts
> 
> xyz.hosts:3: ignoring out-of-zone data (xyz.local)
> xyz.hosts:15: ignoring out-of-zone data (DeadStick.xyz.local)
> 
> 
> 
> 1$ORIGIN .
> 2$TTL 86400; 1 day
> 3xyz.localIN SOAxyz.local. root\@rn6.xyz.local. (
> 4265; serial
> 510800  ; refresh (3 hours)
> 63600   ; retry (1 hour)
> 7360; expire (5 weeks 6 days 16 hours)
> 886400  ; minimum (1 day)
> 9)
>10NSxyz.local.
>11A192.168.255.10
>12MX10 xyz.local.
>13$ORIGIN xyz.local.
>14$TTL 3600; 1 hour
>15DeadStickA192.168.255.156
>16TXT"310702541c5622d0e6001136bd71a6578b"
> 
> ___
> 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

named reload and HTTPS certs

[Eric Germann via bind-users]

There’s been some great discussion lately on enabling DoH with LetsEncrypt 
certs.

My question is this:  If I renew the cert while named is running and do a 
reload on it, is that enough to pick up the new certs or do I need to 
stop/start the named process?

Basically, does reload only reload the zones or the entire config and 
subordinate files?

Thanks

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1









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: No more support for windows

[Eric Germann via bind-users]

Call me naive, but I’m trying to figure out what the corner case is to use BIND 
on Windows.

For an internal network Windows Server already has a name server that 
integrates with AD and everything else needed to run a Windows network.  
Support for DDNS is a lot easier, it has tons of SRV records needed for service 
location, etc.  It seems it would be a lot easier to use that for a Windows 
network than shoehorn everything in to BIND.

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann 
 
Twitter: @ekgermann
Telegram || Signal || Phone +1 {dash} 419 {dash } 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







> On Jun 4, 2021, at 4:58 PM, Gregory Sloop  wrote:
> 
> This feels a lot like responding to trolls, but I'll instead assume that 
> you're asking (or making a point) in good faith.
> 
> So, we'll stipulate that - you're actually interested in truth and knowledge.
> 
> So, it's easily compiled on Mac, Unix, FreeBSD, Linux, SunOS, RaspPi, etc.
> And it compiles on a huge range of hardware, CPU's etc.
> 
> I'd consider that highly portable.
> 
> You're welcome to disagree, but then someone else will complain it's not 
> available in Amiga, Atari and under Dos and complain it isn't "portable" 
> because there's no dos version.
> 
> So how many platforms do you have to support, to call it portable?
> (I've always thought of "portable" code, in this context especially, as code 
> that is kept open so it will fairly easily compile on any *nix/posix platform 
> without too much drama. And I think that's a pretty universal understanding 
> for *nix style code.)
> 
> So, it seems you are tilting at windmills, complaining about Windows only.
> 
> Yes, the fundamentals of Windows are *VERY* different than any 
> Linux/Unix/Solaris etc based platform. As such, making it work across all 
> those platforms is really quite a lot of work.
> (Making it work fine, even on the future supported platforms (*nix) isn't 
> trivial - obviously adding Windows to the mix is far, far more!)
> 
> And, it seems like no-one has stepped up to commit the $$$ needed to keep 
> that support going.
> Even a cheap dev probably charges $100+ an hour. How many hours/dollars do 
> you think, in aggregate, is committed to keeping Windows support? It's not 
> going to be like buying a $3 app for your phone - since the market for 
> Windows users is far smaller.
> 
> And, I suspect, if we reach the end of the road for Windows support, and 
> there's a half million users out there that want BIND supported on Windows, 
> and they'll all pledge a buck a year, than I'd expect that Windows support 
> will roll right out.
> 
> But if instead there's 100 people willing to pledge even $100 a year, well 
> I'd guess that's not likely to pay for it.
> 
> ISC manages to pay the people who write code and do support through support 
> contracts. Do you have one of those?
> 
> So the last option is;
> You, or someone else to simply give away their time for free.
> You up for that?
> If you're not, or you don't have that skill set, then complaining bitterly 
> seems a little hypocritical.
> 
> ISC already releases a huge set of software that you almost certainly use 
> every single day (DHCP server and clients, along with BIND) and they aren't 
> charging you a dime for that use. They're not charging your ISP either, or a 
> ton of other people. So, IMO, they've really done a ton of free work for the 
> community already.
> 
> But it seems like you think it's not enough.
> 
> Sigh.
> What. Can. I. Say.
> ISC does a lot of really good work.
> IMO, this kind of a complaint is really misplaced.
> 
> And to be clear, I won't engage in a bunch of back-and-forth arguing this 
> position. You're welcome to agree or not.
> But *I* think you're obviously wrong, and I want everyone at ISC who does all 
> that good work, developing great software that they let us use for free that 
> I really appreciate their work.
> 
> -Greg
> 
> 
> 
> PC> What I find ironic is that here:
> 
> PC> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/README.md 
> 
> 
> PC> the very first line says:
> 
> PC> "BIND (Berkeley Internet Name Domain) is a complete, highly portable
> PC> implementation of the Domain Name System (DNS) protocol."
> 
> PC> If this were truly the case, BIND would work on Windows (or any other
> PC> platform that doesn't have a "u" in it's name) with minimal effort
> PC> and would not require specific funding to adapt it to any particular
> PC> platform.
> 
> PC> Can we please have a realistic definition of what BIND is and what
> PC> it's objectives are?
> 
> PC> I for one would be more likely to contribute to the development of
> PC> a non-platform-specific, portable BIND than a single-platform-specific
> PC> one.
> 
> PC> On the ot