Re: CNAME and IPv6

Am 30.05.2024 um 00:47:56 Uhr schrieb Peter: > On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas > wrote: ! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock > wrote: ! > > rinetd manages 2 separate connections and should work > with PMTUD. ! > ! On 28.05.24 22:17, Peter

Re: CNAME and IPv6

On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas wrote: ! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote: ! > > rinetd manages 2 separate connections and should work with PMTUD. ! ! On 28.05.24 22:17, Peter wrote: ! > I'm wondering how it would. The connections are

Re: issue with forwarder zones

Hi Brian. We're going to need some details please, like for starters: - What's the domain being queried? - A network diagram showing where your BIND server is and what it's forwarding to. - IP addresses of everything. - A packet capture (binary pcap format, not a snippet or a screenshot) from your

issue with forwarder zones

My bad - I'd mailed this mistakenly to an individual and not the list. --- I am currently running BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu. I am sometimes seeing that I don't have resolution for some FQDN in forwarder zones. Usually it works, sometimes I don't get resolution. Interesting I failed

Re: [DNSSEC] testing KASP

On 29. 05. 24 11:31, adrien sipasseuth wrote: Only if KSK has DSState: rumoured. If the DSState is hidden it means that it is not expected to be in the parent (for example because the DNSKEY has not yet been fully propagated). > Do you need to withdraw the old key too immediatly ? anything

Re: CNAME and IPv6

On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote: rinetd manages 2 separate connections and should work with PMTUD. On 28.05.24 22:17, Peter wrote: I'm wondering how it would. The connections are TCP, the PMTU works via ICMP6. No, Path MTU discovery works with TCPv4 using ICMPv4

Re: [DNSSEC] testing KASP

Only if KSK has DSState: rumoured. If the DSState is hidden it means that it is not expected to be in the parent (for example because the DNSKEY has not yet been fully propagated). > Do you need to withdraw the old key too immediatly ? anything else to do ? >>> Do you mean withdraw the old DS?

Re: Debugging TSIG signed nsupdate problems - Specifically a logging question

In the dnssec.log file I only found references to normal key rotation. Adding the section for update_security and running at trace 99 didn't provide _any_  update_security log output, nor did it provide any extra output to the update log. even when running in single combined log format I

Re: CNAME and IPv6

On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote: > Am 28.05.2024 um 18:48:38 Uhr schrieb Peter: > > > On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote: > > > > > Now we add an IPv6 address for 'myhost'. But portforwarding > > > > doesn't work for IPv6. Instead we are

Re: CNAME and IPv6

Am 28.05.2024 um 18:48:38 Uhr schrieb Peter: > On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote: > ! > Now we add an IPv6 address for 'myhost'. But portforwarding > ! > doesn't work for IPv6. Instead we are required to use different > ! > addresses all over, like so: > ! > ! port

Re: CNAME and IPv6

On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote: ! Am 28.05.2024 um 12:00:09 Uhr schrieb Peter: ! ! > if I understand corrently, the use of CNAME is just a convenience ! > and no technical feature, right? ! ! It is technical because the query is redirected to the domain listed in !

Re: CNAME and IPv6

Am 28.05.2024 um 12:00:09 Uhr schrieb Peter: > if I understand corrently, the use of CNAME is just a convenience > and no technical feature, right? It is technical because the query is redirected to the domain listed in the CNAME. > In lots of examples on the net, a zonefile for a domain

CNAME and IPv6

Hello, if I understand corrently, the use of CNAME is just a convenience and no technical feature, right? In lots of examples on the net, a zonefile for a domain might contain things similar to this: @ORIGIN example.com. .. myhost A1.2.3.4 www

Re: Debugging TSIG signed nsupdate problems - Specifically a logging question

Please allow me to refocus this thread to the original question. I'm asking about the logging facility with respect to the "update" section of code in ISC's bind9 product. Yes, I understand update-policy choices/errors will generate the REFUSED response. _I'm only asking about the logging

Re: Debugging TSIG signed nsupdate problems

> On 27 May 2024, at 16:06, Erik Edwards via bind-users > wrote: > > Hello Mark & List, > > Thank you for responding, I'm running bind-9.18.26-1.fc40.x86_64 and using > nsupdate 9.16.27-Debian to send the updates, using rndc Version: 9.18.26. > > I'm issuing commands through rndc to set the

To the last windows Bind

Eagle-Eye Cherry - Save Tonight (youtube.com) -- 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

Re: Debugging TSIG signed nsupdate problems

Hello Mark & List, Thank you for responding, I'm running bind-9.18.26-1.fc40.x86_64 and using nsupdate 9.16.27-Debian to send the updates, using rndc Version: 9.18.26. I'm issuing commands through rndc to set the trace level to 99 -> "rndc trace 99". rndc seems to work correctly in all

Re: Debugging TSIG signed nsupdate problems

Start from the beginning. Show the actual configuration (named.conf, K* files, etc.). X out the secret keys. Show the actual commands you are running. Show the actual logs being produced. REFUSED can come from lots of things. Named emits log messages for almost all of them without needing to

Re: CIDR notation for RPZ rpz-ip ?

On 2024-05-17 19:37, Nick Tait via bind-users wrote: On 18/05/2024 09:11, J Doe wrote: Hello, When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used or must they be either: /8, /16, /24, /32 for IPv4 ? For example, if I want to block records with an A address of

Re: Debugging TSIG signed nsupdate problems

algorithm hmac-sha256; named-checkconf -p shows the key with the matching name, algo, and secret. When I mis-configure, change, or typo the secret it returns "BAD SECRET" The error I'm seeing is "REFUSED" on a config that worked until the upgrade. It worked on F36-F39, upgrades were seamless.

Re: Debugging TSIG signed nsupdate problems

It doesn't answer your original question, but I suggest looking at the 'algorithm' of that key. Might it be a hmac-md5 ? If you 'named-conf -px'   does it appear in the list of keys? -- Do things because you should, not just because you can. John Thurston907-465-8591

Debugging TSIG signed nsupdate problems

How can I set debug level log for update events? I've tried "rndc trace 99" which gives *lots* of information expect for UPDATE REFUSED issues even thought the channel is set to dynamic severity. Is there a different way to get named to generate debug level logs for UPDATE events? I'm

Re: Counters for DNS transports?

> this has been planned, but unfortunately other stuff got into the way. > > It is still on our roadmap though. OK, thanks, it's reassuring that I hadn't overlooked something this time around, and it's good to see it's already thought about and on your roadmap. It's also on my wishlist, FWIW. :)

Re: Counters for DNS transports?

Hi Havard, this has been planned, but unfortunately other stuff got into the way. It is still on our roadmap though. Ondřej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

Re: Make dig and nslookup DNSSEC aware?

Odd numbers (9.17, 9.19…) are the development versions. Even numbers (9.18, 9.20 - soon…) are the production versions, based on the odd-numbered version before. So 9.18.27 (currently) would be the one to go for. Cheers, Greg > On 22 May 2024, at 16:53, Robert Wagner wrote: > >

Re: Counters for DNS transports?

> I frontend DoH and DoT traffic with nginx and use that for > analytics/statistics. Thanks, but I think that violates the KISS principle. Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software

Re: Make dig and nslookup DNSSEC aware?

https://www.isc.org/blogs/bind-doh-update-2021/ BIND DoH Update Status of DNS-over-HTTPS support in BIND 9 as of March, 2021 The latest development release of BIND 9 contains a significant number of improvements to DNS-over-HTTP (DoH). www.isc.org

Re: Counters for DNS transports?

I frontend DoH and DoT traffic with nginx and use that for analytics/statistics. Cheers, David On Wed, May 22, 2024 at 11:08 AM Havard Eidnes via bind-users < bind-users@lists.isc.org> wrote: > Hi, > > I recently had reason to enable BIND 9.18.27 to do DoT and DoH > (done via unbound earlier),

Re: Make dig and nslookup DNSSEC aware?

> Doesn't dig already offer DoT using +tls and DoH using +https? You're right, it does. I need to sort out my $PATH... Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support

RE: Make dig and nslookup DNSSEC aware?

Doesn't dig already offer DoT using +tls and DoH using +https ? Don Friesen -Original Message- From: bind-users On Behalf Of Ondrej Surý Sent: Wednesday, May 22, 2024 8:09 AM To: Havard Eidnes Cc: bind-users@lists.isc.org Subject: Re: Make dig and nslookup DNSSEC aware? [EXTERNAL]

Re: Make dig and nslookup DNSSEC aware?

forget about nslookup. deprecated in my mind. use dig like so: for DoT: $dig @1.1.1.1 -tA +dnssec +tls www.google.com for Doh: dig @1.1.1.1 -ta +https +dnssec www.google.com Make sure you have a more recent version of dig to supports this. If you need programmatic DNSSEC access use a library

Re: Make dig and nslookup DNSSEC aware?

> On 22. 5. 2024, at 17:02, Havard Eidnes via bind-users > wrote: > > And, no, I'm not aware of any such plans to incorporate a DNSSEC > validator in any of those tools. Not sure it makes technical > sense, as it's a fairly large task. That's what a validating > recursive resolver does; watch

Counters for DNS transports?

Hi, I recently had reason to enable BIND 9.18.27 to do DoT and DoH (done via unbound earlier), and it all appears to work well so far. I have configured statistics-channels { inet 127.0.0.1 port 8053 allow { 127.0.0.1; }; inet port 8053 allow { blah; }; }; The former for

Re: Make dig and nslookup DNSSEC aware?

>> Sorry if this has already been hashed through, but I cannot >> find anything in the archive. Is there any chance someone can >> make dig and nslookup DNSSEC aware and force it to use DoT or >> DoH ports - TCP 443 or 853 only? > > Not sure about that. However, the "kdig" utility from the

Re: Make dig and nslookup DNSSEC aware?

> Sorry if this has already been hashed through, but I cannot > find anything in the archive. Is there any chance someone can > make dig and nslookup DNSSEC aware and force it to use DoT or > DoH ports - TCP 443 or 853 only? Not sure about that. However, the "kdig" utility from the "knot" name

Make dig and nslookup DNSSEC aware?

Sorry if this has already been hashed through, but I cannot find anything in the archive. Is there any chance someone can make dig and nslookup DNSSEC aware and force it to use DoT or DoH ports - TCP 443 or 853 only? RW -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe

RE: named fails to start with bind-9.18.0

No idea what OS or product. This is a compile, as in build the binary, or a daemon run issue? For myself I have an Ubuntu base and am running IND 9.18.x. Not locally compiled. I have found journalctl, systemctl, bind logs and /usr/bin/named-checkconf and named-checkzone to be very useful.

Re: named fails to start with bind-9.18.0

Assurance you are actually trying to compile current code. A statement of what your operating system is. Actual output of your compile steps. Actual logged output of your attempt to launch. -- Do things because you should, not just because you can. John Thurston907-465-8591

Re: named fails to start with bind-9.18.0

As Ondrej said. Upgrade. You compiled BIND 9.18.0. That is 27 release behind current. Unless you are doing archaeological investigations of old code you shouldn’t be trying to use old code like that. Running newer code means that you can avoid all the bugs that have been fixed in the

Re: named fails to start with bind-9.18.0

My Apologies. I was just trying to show the snippet of bind library code where named was failing. I am trying to run named after compiling the bind library. The command I use to run named is as follows: /bin/named -c /etc/named.conf It appears that it is failing when it tries to daemonize

Re: RFC8482: Implementation through HINFO record

And named already handles ANY being used as an reflection amplifier. This was written for servers using databases where getting the ANY response is actually hard. Cloudflare was using a response model that most thought was not really correct but wasn’t broken enough to say “Don’t do that”. If

Re: named fails to start with bind-9.18.0

> Can someone please help what could be the issue here? Not really. First start by using the latest 9.18 version and not something that’s two years old and then you need to provide more information than a screenshot of random code snippet. If you want free help you need to provide information

named fails to start with bind-9.18.0

Hi All, I compiled bind-9.18.0 successfully but when I try to run named via configuration file, named exits with return code 1. The below code in bin/named/os.c is where it is failing. [image: image.png] When i run named with gdb , i see that it is exiting in the above code. Can someone

Re: RFC8482: Implementation through HINFO record

I would suggest you to create a feature request in our GitLab. This way it won't get lost in the tides of time. Personally, I actually quite like the idea, but it would have to be an option to turn off and on, so it's not going to save us from having a code that supports ANY anyway. Ondřej --

Re: RFC8482: Implementation through HINFO record

Named does not support this. There is no requirement to support this. -- Mark Andrews > On 21 May 2024, at 00:04, Amaury Van Pevenaeyge > wrote: > >  > Hello everyone, > > How is it possible to set up a resource record of type HINFO so that it is > returned on every ANY request without

RFC8482: Implementation through HINFO record

Hello everyone, How is it possible to set up a resource record of type HINFO so that it is returned on every ANY request without all the other records in the zone? I'm looking to implement RFC8482 as Cloudflare can do in the following article:

Re: queries for "_.domain"

On 18.05.24 07:10, Mark Andrews wrote: Correct. Later versions use NS queries as that allows named to cache the non-existence of the NS RRset. I see this happened since 9.18.17 Luckily Debian 11/backports and Debian 12 have incorporated this version. Using _.domain doesn’t allow that to

Re: Missing cookie

> On 20 May 2024, at 07:37, J Doe wrote: > > Hi list, > > I run a validating recursive resolver with BIND 9.18.27. Over the > course of many days, I have noted the following warning about a missing > cookie from a particular server: > >09-May-2024 20:09:22.277 resolver: info: missing

Missing cookie

Hi list, I run a validating recursive resolver with BIND 9.18.27. Over the course of many days, I have noted the following warning about a missing cookie from a particular server: 09-May-2024 20:09:22.277 resolver: info: missing expected cookie from 192.5.5.241#53 This server runs

RHEL, Centos, Rocky, Fedora rpm 9.18.27

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies.

Re: CIDR notation for RPZ rpz-ip ?

On 18/05/2024 09:11, J Doe wrote: Hello, When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used or must they be either: /8, /16, /24, /32 for IPv4 ? For example, if I want to block records with an A address of 192.168.10.1, I know I can write:     32.1.10.168.192.rpz-ip  

CIDR notation for RPZ rpz-ip ?

Hello, When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used or must they be either: /8, /16, /24, /32 for IPv4 ? For example, if I want to block records with an A address of 192.168.10.1, I know I can write: 32.1.10.168.192.rpz-ipINCNAME . ... and records

Re: queries for "_.domain"

Correct. Later versions use NS queries as that allows named to cache the non-existence of the NS RRset. Using _.domain doesn’t allow that to happen. NS queries do however expose broken delegations. Make sure you have working NS records at the zone apex and at the delegation point. This is

Re: queries for "_.domain"

On Fri, May 17, 2024 at 03:25:01PM +0200, Matus UHLAR - fantomas wrote a message of 43 lines which said: > I have noticed that BIND sends strange (for me) queries. > > 5 0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A > _.net.akadns.net OPT QNAME minimisation

queries for "_.domain"

Hello, I have noticed that BIND sends strange (for me) queries. 5 0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A _.net.akadns.net OPT 8 0.204738 193.108.88.128 → 192.168.0.1 DNS 159 Standard query response 0x15a4 No such name A _.net.akadns.net SOA

Re: [DNSSEC] testing KASP

Hi, On 5/16/24 14:02, adrien sipasseuth wrote: Hello, I try to set up a testing environment in order to create some scripts for automated the roll over KSK. # question 1 # this is my policy : dnssec-policy "test" {     keys {     ksk lifetime P3D algorithm

[DNSSEC] testing KASP

Hello, I try to set up a testing environment in order to create some scripts for automated the roll over KSK. # question 1 # this is my policy : dnssec-policy "test" { keys { ksk lifetime P3D algorithm ecdsa256 2048; zsk lifetime P1D algorithm

Re: SRV on multiple subdomains

Adding my 2p, I would take that principle a step further. Create a generic, unique SRV record that represents what you want to happen. Then create specific CNAME records for each server. The reasons for the extra, generic record are that it represents the service you want to offer and all

Re: SRV on multiple subdomains

On 14 May 2024, at 15:20, DEMBLANS Mathieu wrote: A part of the subdomains are managed by us, others subdomains by an other entity. So we can't configure a generic target for all subdomains as each entity has its own target for SRV entries. -Message d'origine- De : bind-users

Re: bind_dlz and views and samba

On 15. 05. 24 17:21, Peter Carlson wrote: As I understand it bind_dlz does not support multiple views, I have to following scenario and am trying to figure out how to configure it: * Internal (192.168.10.0/24) o resolve internal domain xyz.com o resolve internal samba domain

bind_dlz and views and samba

As I understand it bind_dlz does not support multiple views, I have to following scenario and am trying to figure out how to configure it: * Internal (192.168.10.0/24) o resolve internal domain xyz.com o resolve internal samba domain xyz.lab o resolve single address xyz.3cx.us

Re: SRV on multiple subdomains

On 14.05.24 14:20, DEMBLANS Mathieu wrote: A part of the subdomains are managed by us, others subdomains by an other entity. If you really have multiple subdomains for exanmle.com managed by different entities, then yes, wildcard is not good idea. This applies to A and MX records as well.

Re: Special-use names and RPZ

> On 15 May 2024, at 04:34, John Thurston wrote: > > There are several 'special-use' domain names I'm pondering > • invalid. > • test. > • onion. > My read of the RFCs indicate they should result in NXDOMAIN, and not be > passed for resolution. > RFC 6761 (test. Section 6.2.4 /

Re: Special-use names and RPZ

On Tue, May 14, 2024 at 2:34 PM John Thurston wrote: > > There are several 'special-use' domain names I'm pondering > > invalid. > test. > onion. > > My read of the RFCs indicate they should result in NXDOMAIN, and not be > passed for resolution. > > RFC 6761 (test. Section 6.2.4 / invalid.

Special-use names and RPZ

There are several 'special-use' domain names I'm pondering * invalid. * test. * onion. My read of the RFCs indicate they should result in NXDOMAIN, and not be passed for resolution. RFC 6761 (test. Section 6.2.4 / invalid. Section 6.4.4) caching DNS servers SHOULD, by default, generate

RE: SRV on multiple subdomains

A part of the subdomains are managed by us, others subdomains by an other entity. So we can't configure a generic target for all subdomains as each entity has its own target for SRV entries. -Message d'origine- De : bind-users De la part de Matus UHLAR - fantomas Envoyé : mardi 14 mai

Re: SRV on multiple subdomains

Le 14/05/2024 à 15:08, DEMBLANS Mathieu a écrit : Hello, I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,…). For A and MX entries,

Re: SRV on multiple subdomains

On 14.05.24 13:08, DEMBLANS Mathieu wrote: I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,...). For A and MX entries, we use a general

SRV on multiple subdomains

Hello, I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,...). For A and MX entries, we use a general domain definitions with wildcard but

Re: Truncated TCP ?

On 2024-05-05 20:47, Mark Andrews wrote: On 6 May 2024, at 07:38, J Doe wrote: Hello, I run BIND 9.18.26 as a recursive, validating resolver. In my logs, I noticed the following: 01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response resolving

Re: Switching from rhel base 9.16 to 9.18 copr

This doesn't answer the question you have asked, so feel free to hit 'delete'. I suggest that what you are trying to do has the potential to cause you suffering later. If you are switching to the COPR distribution, don't fight it. Turn off and disable the base service/daemon. Copy your .conf

Re: Truncated TCP ?

> On 6 May 2024, at 07:38, J Doe wrote: > > Hello, > > I run BIND 9.18.26 as a recursive, validating resolver. In my logs, I > noticed the following: > >01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response >resolving 'www.ipfire.org/A/IN': 74.113.60.134#53 > > I

Truncated TCP ?

Hello, I run BIND 9.18.26 as a recursive, validating resolver. In my logs, I noticed the following: 01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response resolving 'www.ipfire.org/A/IN': 74.113.60.134#53 I am aware that there are issues with DNS UDP traffic being

Re: Switching from rhel base 9.16 to 9.18 copr

I used these symlinks to transition from RHEL standard 9.16 to COPR 9.18 ln -s /var/opt/isc/scls/isc-bind/named /var/named ln -s /etc/opt/isc/scls/isc-bind/named.conf /etc/named.conf ln -s /var/opt/isc/scls/isc-bind/run/named /run/named ln -s /opt/isc/isc-bind/root/usr/sbin/rndc /usr/sbin/rndc

Re: Switching from rhel base 9.16 to 9.18 copr

On Sun, May 05, 2024 at 06:15:13PM +0200, Luca vom Bruch via bind-users wrote: ! Hello, ! ! I use bind (stock from alma 9.3) as a nameserver for a webhosting server ! with webmin/virtualmin. ! ! If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of ! 9.18 - I want to

Switching from rhel base 9.16 to 9.18 copr

Hello, I use bind (stock from alma 9.3) as a nameserver for a webhosting server with webmin/virtualmin. If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of 9.18 - I want to experiment with DoT for opportunistic TLS between nameservers, upcoming standard

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

> On 1 May 2024, at 22:25, Walter H. via bind-users > wrote: > > On 01.05.2024 01:33, Mark Andrews wrote: >> >>> On 1 May 2024, at 03:32, Lee wrote: >>> >>> On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: On 29.04.2024 22:19, Lee wrote: > On Sun, Apr 28, 2024 at 2:18 AM Walter

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On 01.05.2024 01:33, Mark Andrews wrote: On 1 May 2024, at 03:32, Lee wrote: On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

> On 1 May 2024, at 03:32, Lee wrote: > > On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: >> >> On 29.04.2024 22:19, Lee wrote: >>> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users >>> wrote: >>> >>> something that I replied to and got this in response: >>> >>> Error Icon >>>

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Tue, Apr 30, 2024 at 2:40 AM Mark Andrews wrote: > > And it has been fixed. Yay! No more error messages in the log because of them :-) Thanks for your help Lee -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: > > On 29.04.2024 22:19, Lee wrote: > > On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users > > wrote: > > > > something that I replied to and got this in response: > > > > Error Icon > > Message blocked > > Your message to

Re: named 100% utilization

> BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu (Extended Support Version) I would start here - ISC provides packages for RedHat, Fedora, Debian and Ubuntu with latest upstream version. There's little point in debugging a version that's old and doesn't contain all the bugfixes. If you can reproduce

named 100% utilization

we are having a problem with bind that has been happening for about a week. one of named's threads goes to 100% and then named stops responding to any dns requests.  I have logging turned on and dont see anything out of the ordinary.  It's not crashing. Any recommendations on where to start

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

And it has been fixed. % dig dnssec-analyzer.verisignlabs.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9048 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1,

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

> On 30 Apr 2024, at 13:39, Walter H. via bind-users > wrote: > > On 29.04.2024 22:19, Lee wrote: >> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users >> wrote: >> >> something that I replied to and got this in response: >> >> Error Icon >> Message blocked >> Your message to

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Mon, Apr 29, 2024 at 5:13 PM Mark Andrews wrote: > > I prefer to only name and shame when I’m 100% sure of the target. I was only trying to understand why I was getting a SERVFAIL, there was no intention to name & shame. Regards, Lee "name & shame" was not my intent. > > -- > Mark Andrews >

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

I prefer to only name and shame when I’m 100% sure of the target. -- Mark Andrews > On 30 Apr 2024, at 06:56, Lee wrote: > > On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: >> >> It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it >> serves .com rather than

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: > > It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it > serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is > actually delegated to it. > > % dig dnssec-analyzer-gslb.verisignlabs.com +trace

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

And the SMTP server doesn’t need to listen on IPv6 if it isn’t going to accept messages over that transport. Talk about a way to DoS yourself. -- Mark Andrews > On 30 Apr 2024, at 06:19, Lee wrote: > > On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users > wrote: > > something that I

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The response from the remote server was: 554

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Sun, Apr 28, 2024 at 2:18 AM Walter H. wrote: > > On 27.04.2024 16:54, Lee wrote: > > On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users > > wrote: > >> # host dnssec-analyzer.verisignlabs.com > >> dnssec-analyzer.verisignlabs.com is an alias for > >>

Re: Question about resolver

This looks like Google has forgotten to create the zone 96.34.in-addr.arpa but have created 180.96.34.in-addr.arpa resulting in answers that should come from 96.34.in-addr.arpa getting REFUSED returned. DNSSEC validation and QNAME minimisation find these sorts of configuration errors.

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is actually delegated to it. % dig dnssec-analyzer-gslb.verisignlabs.com +trace +all ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.24-dev <<>>

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

|Try these four | | | |fail01.dnssec.works| |fail02.dnssec.works| |fail03.dnssec.works| |fail04.dnssec.works| and then with   +cd and note the difference; On 28.04.2024 08:17, Walter H. via bind-users wrote: On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via

Re: [help]how to configure ecs subnet for bind-9.18-21

OK. Firstly, the bad news. ECS is only available in the subscription version of BIND. That is, versions ending with -S. To get this version you need a (paid) support contract with ISC. If you are interested, let me know. Secondly, 9.18.21 is not current. I would recommend that you use the

Re: [help]how to configure ecs subnet for bind-9.18-21

Hello. Do you mean 9.18-S1? > On 28 Apr 2024, at 08:06, Yang via bind-users > wrote: > > > dear admin: > now, i use bind-9.18-21, i want to use ecs client subnet function; but i > don't know how to configure it, and i don't get method from google > please give me some example,or

[help]how to configure ecs subnet for bind-9.18-21

dear admin: now, i use bind-9.18-21, i want to use ecs client subnet function; but i don't know how to configure it, and i don't get method from google please give me some example,or document , or google links to learn about it ; thanks! Yang 395096...@qq.com-- Visit

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: # host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42

Re: Question about resolver

On 2024-04-26 16:45, Josh Kuo wrote: In this particular case, isn't the resolver attempting to do a reverse lookup of the IP address that's listed ? You are right, I missed that this is a reverse-mapping zone. In that case, run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa"

  1   2   3   4   5   6   7   8   9   10   >