Re: RFC8482: Implementation through HINFO record

[Mark Andrews]

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 their 
customers where happy with this behaviour then ok.  This RFC was written to 
allow them to continue doing what they where doing without having to fight that 
they where not RFC compliant. It was not written to say this is how you should 
respond to ANY.  It also requires online signing for DNSSEC or adding a HINFO 
record for every name in your zone when offline signing. 

Mark
-- 
Mark Andrews

> On 21 May 2024, at 00:31, Ondřej Surý  wrote:
> 
> 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
> --
> 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.
> 
>> On 20. 5. 2024, at 16:03, 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 all the other records in the zone? I'm 
>> looking to implement RFC8482 as Cloudflare can do in the following article: 
>> https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any
>> 
>> Thanks in advance for your help.
>> -- 
>> 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

-- 
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: RFC8482: Implementation through HINFO record

[Ondřej Surý]

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
--
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.

> On 20. 5. 2024, at 16:03, 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 all the other records in the zone? I'm 
> looking to implement RFC8482 as Cloudflare can do in the following article: 
> https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any
> 
> Thanks in advance for your help.
> -- 
> 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: RFC8482: Implementation through HINFO record

[Mark Andrews]

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 all the other records in the zone? I'm 
> looking to implement RFC8482 as Cloudflare can do in the following article: 
> https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any
> 
> Thanks in advance for your help.
> -- 
> 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

RFC8482: Implementation through HINFO record

[Amaury Van Pevenaeyge]

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: 
https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any

Thanks in advance for your help.
-- 
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: record PTR

[sami . rahal]

It's clear, thank you.

De : Ben Croswell 
Envoyé : jeudi 14 mars 2024 13:26
À : RAHAL Sami SOFRECOM ; ML BIND Users 

Objet : Re: record PTR

181.242.197.in-addr.arpa. 3600 IN NS 
douala0.orange.cm<http://douala0.orange.cm>.
181.242.197.in-addr.arpa. 3600 IN NS nsbangui.orangerca.com.
181.242.197.in-addr.arpa. 3600 IN NS 
yaounde0.orange.cm<http://yaounde0.orange.cm>.

The in-addr currently points to the DNS servers above. Those would need to be 
changed to your servers or the owners of those servers would need to add the 
PTR records.

On Thu, Mar 14, 2024, 8:19 AM 
mailto:sami.ra...@sofrecom.com>> wrote:
Thank you for your response.
In my case, I have added a PTR record for mail.sami.tn<http://mail.sami.tn> 
pointing to 197.242.181.69, but it is still not visible from the outside. 
However, when I test 'dig @0 -x 197.242.181.69', it works. Do I need to request 
a delegation of 197.242.181.69 to the name servers 
ns1.sami.tn<http://ns1.sami.tn>?

De : Ben Croswell mailto:ben.crosw...@gmail.com>>
Envoyé : jeudi 14 mars 2024 13:10
À : RAHAL Sami SOFRECOM 
mailto:sami.ra...@sofrecom.com>>; ML BIND Users 
mailto:bind-users@lists.isc.org>>
Objet : Re: record PTR

The in-addr.arpa domain for your IP space will need to be delegated to your DNS 
servers. That generally happens at the entity that assigned the block. For 
instance ARIN, RIPE, or APNIC.

On Thu, Mar 14, 2024, 8:06 AM 
mailto:sami.ra...@sofrecom.com>> wrote:
Hello, please, I want to know if I need to delegate a range of IP addresses to 
my authoritative DNS server with my registrar before creating a PTR record or 
not. In other words, if I want to create a PTR record on my authoritative 
server (ns1.mydomain.com<http://ns1.mydomain.com>) for 
mail.mydomain.com<http://mail.mydomain.com> pointing to 41.226.22.50, should 
the range 41.226.22.0/24<http://41.226.22.0/24> be delegated to my 
authoritative DNS server ns1.mydomain.com<http://ns1.mydomain.com>?
Regards Sami
--
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<mailto: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: record PTR

[Ben Croswell]

181.242.197.in-addr.arpa. 3600 IN NS douala0.orange.cm.
181.242.197.in-addr.arpa. 3600 IN NS nsbangui.orangerca.com.
181.242.197.in-addr.arpa. 3600 IN NS yaounde0.orange.cm.

The in-addr currently points to the DNS servers above. Those would need to
be changed to your servers or the owners of those servers would need to add
the PTR records.

On Thu, Mar 14, 2024, 8:19 AM  wrote:

> Thank you for your response.
>
> In my case, I have added a PTR record for mail.sami.tn pointing to
> 197.242.181.69, but it is still not visible from the outside. However, when
> I test 'dig @0 -x 197.242.181.69', it works. Do I need to request a
> delegation of 197.242.181.69 to the name servers ns1.sami.tn?
>
>
>
> *De :* Ben Croswell 
> *Envoyé :* jeudi 14 mars 2024 13:10
> *À :* RAHAL Sami SOFRECOM ; ML BIND Users <
> bind-users@lists.isc.org>
> *Objet :* Re: record PTR
>
>
>
> The in-addr.arpa domain for your IP space will need to be delegated to
> your DNS servers. That generally happens at the entity that assigned the
> block. For instance ARIN, RIPE, or APNIC.
>
>
>
> On Thu, Mar 14, 2024, 8:06 AM  wrote:
>
> Hello, please, I want to know if I need to delegate a range of IP
> addresses to my authoritative DNS server with my registrar before creating
> a PTR record or not. In other words, if I want to create a PTR record on my
> authoritative server (ns1.mydomain.com) for mail.mydomain.com pointing to
> 41.226.22.50, should the range 41.226.22.0/24 be delegated to my
> authoritative DNS server ns1.mydomain.com?
>
> Regards Sami
>
> --
> 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: record PTR

[Marco Moock]

Am 14.03.2024 schrieb sami.ra...@sofrecom.com:

> Hello, please, I want to know if I need to delegate a range of IP
> addresses to my authoritative DNS server with my registrar before
> creating a PTR record or not. In other words, if I want to create a
> PTR record on my authoritative server (ns1.mydomain.com) for
> mail.mydomain.com pointing to 41.226.22.50, should the range
> 41.226.22.0/24 be delegated to my authoritative DNS server
> ns1.mydomain.com?

The reverse zone for your net/IP needs to be delegated, nothing more.
That needs to be done by your ISP because not by your domain registrar.

If you only want to set some PTRs in your address range, the range will
be delegated and you only set the PTRs you need.
-- 
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: record PTR

[Ben Croswell]

The in-addr.arpa domain for your IP space will need to be delegated to your
DNS servers. That generally happens at the entity that assigned the block.
For instance ARIN, RIPE, or APNIC.

On Thu, Mar 14, 2024, 8:06 AM  wrote:

> Hello, please, I want to know if I need to delegate a range of IP
> addresses to my authoritative DNS server with my registrar before creating
> a PTR record or not. In other words, if I want to create a PTR record on my
> authoritative server (ns1.mydomain.com) for mail.mydomain.com pointing to
> 41.226.22.50, should the range 41.226.22.0/24 be delegated to my
> authoritative DNS server ns1.mydomain.com?
>
> Regards Sami
> --
> 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

record PTR

[sami . rahal]

Hello, please, I want to know if I need to delegate a range of IP addresses to 
my authoritative DNS server with my registrar before creating a PTR record or 
not. In other words, if I want to create a PTR record on my authoritative 
server (ns1.mydomain.com) for mail.mydomain.com pointing to 41.226.22.50, 
should the range 41.226.22.0/24 be delegated to my authoritative DNS server 
ns1.mydomain.com?
Regards Sami
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Facing issues while resolving only one record

[Mark Andrews]

The servers don’t respond to DNSKEY queries.  No every error is an indication
that the validator should switch tracks from proving an answer is secure (the
server is sending signed responses) to proving that it is insecure.


> On 31 Aug 2023, at 17:28, stuart@registry.godaddy wrote:
> 
> This is odd.
>  “incometax.gov.in” hasn’t published a DS record, so no DNSSEC validation 
> should be occurring for any child. The registry object hasn’t been changed 
> since 2022, so its behaviour should be nothing new.
>  Testing various public verifying resolvers (google, cloudflare, local 
> unbound instances) shows no issue retrieving an A record for 
> eportal.incometax.gov.in., from many places around the world (nlnog ring 
> nodes).
>  So, weird.
>  Stuart Browne
> GoDaddy Registry | Eng - System IVstuart@registry.godaddy
>  i.e. I’m one of the people who maintains the registry and DNS servers for 
> “in” / “gov.in”.
>  From: bind-users  on behalf of Blason R 
> 
> Date: Thursday, 31 August 2023 at 1:42 pm
> To: "Bhangui, Sandeep - BLS CTR" 
> Cc: bind-users 
> Subject: Re: Facing issues while resolving only one record
>  You don't often get email from blaso...@gmail.com. Learn why this is 
> important
> Caution: This email is from an external sender. Please do not click links or 
> open attachments unless you recognize the sender and know the content is 
> safe. Forward suspicious emails to isitbad@.
>  Yes, bypassing DNSSEC Validation seems to have a solution.
>  Thanks for the help.
>  On Wed, Aug 30, 2023 at 7:30 PM Bhangui, Sandeep - BLS CTR via bind-users 
>  wrote:
>> 
>> 
>> This seems to be an issue with the domain incometax.gov.in.
>>  DNSSEC looks like is broken for that domain.
>>  NS servers at our location also cannot resolve that directly  but if I 
>> forward that query to any ISP provider NS which are more lax it resolves 
>> just fine.
>>  Thanks
>> Sandeep
>>  From: bind-users  On Behalf Of John W. 
>> Blue via bind-users
>> Sent: Wednesday, August 30, 2023 9:39 AM
>> To: bind-users 
>> Subject: RE: Facing issues while resolving only one record
>>  CAUTION: This email originated from outside of BLS. DO NOT click (select) 
>> links or open attachments unless you recognize the sender and know the 
>> content is safe. Please report suspicious emails through the “Phish Alert 
>> Report” button on your email toolbar. Recommend you turn off DNSSEC 
>> validation and see if it starts working.
>>  If it does, then you know the issue is with how DNSSEC is configured on 
>> your server.
>>  John
>>  From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
>> Blason R
>> Sent: Wednesday, August 30, 2023 8:20 AM
>> To: bind-users
>> Subject: Facing issues while resolving only one record
>>  Hi all,
>>  I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support 
>> Version)
>> And I am facing this weird issue. Somehow eportal.incometax.gov.in site is 
>> not getting resolved through DNS.
>>  I tried a lot but unfortunately the issue still persists.
>>  Here are packet capture logs.
>>  listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 
>> 262144 bytes
>> 18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+ A? 
>> eportal.incometax.gov.in. (42)
>> 18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53: 
>> 30627+% [1au] A? eportal.incometax.gov.in. (65)
>> 18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+% [1au] 
>> DNSKEY? incometax.gov.in. (57)
>> 18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+% [1au] 
>> DNSKEY? incometax.gov.in. (57)
>> 18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+ 
>> ? eportal.incometax.gov.in. (42)
>> 18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+% [1au] 
>> ? eportal.incometax.gov.in. (65)
>> 18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53: 
>> 16204+% [1au] DNSKEY? incometax.gov.in. (57)
>> 18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53: 
>> 34205+% [1au] ? eportal.incometax.gov.in. (65)
>> 18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+% [1au] 
>> DNSKEY? incometax.gov.in. (57)
>> 18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+ A? 
>> eportal.incometax.gov.in. (42)
>> 18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349 
>> [1au] DNSKEY? incometax.gov.in. (57)
>> 18:47:25.205136 ens18 Out IP 192.168.

Re: Facing issues while resolving only one record

[stuart@registry.godaddy]

This is odd.

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

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

So, weird.


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

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

From: bind-users  on behalf of Blason R 

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

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


Yes, bypassing DNSSEC Validation seems to have a solution.

Thanks for the help.

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

DNSSEC looks like is broken for that domain.

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

Thanks
Sandeep

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

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

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

John

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

Hi all,

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

I tried a lot but unfortunately the issue still persists.

Here are packet capture logs.

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

Re: Facing issues while resolving only one record

[Blason R]

Yes, bypassing DNSSEC Validation seems to have a solution.

Thanks for the help.

On Wed, Aug 30, 2023 at 7:30 PM Bhangui, Sandeep - BLS CTR via bind-users <
bind-users@lists.isc.org> wrote:

> This seems to be an issue with the domain incometax.gov.in.
>
>
>
> DNSSEC looks like is broken for that domain.
>
>
>
> NS servers at our location also cannot resolve that directly  but if I
> forward that query to any ISP provider NS which are more lax it resolves
> just fine.
>
>
>
> Thanks
>
> Sandeep
>
>
>
> *From:* bind-users  *On Behalf Of *John
> W. Blue via bind-users
> *Sent:* Wednesday, August 30, 2023 9:39 AM
> *To:* bind-users 
> *Subject:* RE: Facing issues while resolving only one record
>
>
>
> *CAUTION*: *This email originated from outside of BLS. DO NOT click
> (select) links or open attachments unless you recognize the sender and know
> the content is safe. Please report suspicious emails through the “Phish
> Alert Report” button on your email toolbar. *
>
> Recommend you turn off DNSSEC validation and see if it starts working.
>
>
>
> If it does, then you know the issue is with how DNSSEC is configured on
> your server.
>
>
>
> John
>
>
>
> *From:* bind-users [mailto:bind-users-boun...@lists.isc.org
> ] *On Behalf Of *Blason R
> *Sent:* Wednesday, August 30, 2023 8:20 AM
> *To:* bind-users
> *Subject:* Facing issues while resolving only one record
>
>
>
> Hi all,
>
>
>
> I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support
> Version)
>
> And I am facing this weird issue. Somehow eportal.incometax.gov.in site
> is not getting resolved through DNS.
>
>
>
> I tried a lot but unfortunately the issue still persists.
>
>
>
> Here are packet capture logs.
>
>
>
> listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length
> 262144 bytes
> 18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+
> A? eportal.incometax.gov.in. (42)
> 18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53:
> 30627+% [1au] A? eportal.incometax.gov.in. (65)
> 18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+
> ? eportal.incometax.gov.in. (42)
> 18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+%
> [1au] ? eportal.incometax.gov.in. (65)
> 18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53:
> 16204+% [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53:
> 34205+% [1au] ? eportal.incometax.gov.in. (65)
> 18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+
> A? eportal.incometax.gov.in. (42)
> 18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.205136 ens18 Out IP 192.168.1.133.33517 > 192.36.148.17.53: 18768
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53:
> 28883 [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.259888 ens18 Out IP 192.168.1.133.51762 > 59.160.103.171.53:
> 46716 [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.597312 ens18 In  IP 192.168.1.162.53963 > 192.168.1.133.53: 23+
> ? eportal.incometax.gov.in. (42)
> 18:47:26.498891 ens18 Out IP 192.168.1.133.52631 > 125.16.225.122.53:
> 12762 [1au] DNSKEY? incometax.gov.in. (57)
>
>
>
> I feel this is something related to DNS RRKEY Record size?
>
>
>
> Plus then I dumbdb on my server and went through cache using command
>
> *#rndc dumpdb -all*
>
>
>
> And here is the output
>
>
>
> incometax.gov.in.   3422NS  ns01.incometax.gov.in.
> 3422NS  ns02.incometax.gov.in.
> ns01.incometax.gov.in.  131 \-  ;-$NXRRSET
> ; ns01.incometax.gov.in. RRSIG NSEC ...
> ; ns01.incometax.gov.in. NSEC ns02.incometax.gov.in. A RRSIG NSEC
> ; incometax.gov.in. SOA ns01.incometax.gov.in.
> ns-admin.cpc.incometax.gov.in. 2023060970 7200 3600 1209600 3600
> ; incometax.gov.in. RRSIG SOA ...
> ns02.incometax.gov.in.  120 \-  ;-$NXRRSET
> ; ns02.incometax.gov.in. RRSIG NSEC ...
> ; ns02.incometax.gov.in. NSEC ns03.incometax.gov.in. A RRSIG NSEC
> ; incometax.gov.in. SOA ns02.incometax.gov.in.
> ns-admin.c

Re: Facing issues while resolving only one record

[Bob McDonald]

This is why I try to read this list every day...

Thanks Mark.

I need to go back to RTFM (or read the man page)
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Facing issues while resolving only one record

[Mark Elkins via bind-users]

To disable DNSSEC validation for a domain from the command line - I 
use:   dig +cd eportal.incometax.gov.in 


Works as expected.

Better answer is to get them to fix the problem.

On 2023/08/30 17:08, Bob McDonald wrote:

Turning off validation for that domain fixes the issue.

When using dig to diagnose this issue, one might be tempted to use the 
DNSSEC switch. However, the following command:


dig eportal.incometax.gov.in . +NODNSSEC

will NOT turn off DNSSEC validation.

The DNSSEC switch in dig is used to display the associated DNSSEC 
records (if they exist). It doesn't affect validation. You must make 
the options change indicated by Greg Choules in his previous post to 
disable DNSSEC validation for a specific domain.


Sorry if this is redundant or very rudimentary.

Bob

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 




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

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


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

Re: Facing issues while resolving only one record

[Bob McDonald]

Turning off validation for that domain fixes the issue.

When using dig to diagnose this issue, one might be tempted to use the
DNSSEC switch. However, the following command:

dig eportal.incometax.gov.in. +NODNSSEC

will NOT turn off DNSSEC validation.

The DNSSEC switch in dig is used to display the associated DNSSEC records
(if they exist). It doesn't affect validation. You must make the options
change indicated by Greg Choules in his previous post to disable DNSSEC
validation for a specific domain.

Sorry if this is redundant or very rudimentary.

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

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


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

RE: Facing issues while resolving only one record

[Bhangui, Sandeep - BLS CTR via bind-users]

This seems to be an issue with the domain incometax.gov.in.

DNSSEC looks like is broken for that domain.

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

Thanks
Sandeep

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

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

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

John

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

Hi all,

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

I tried a lot but unfortunately the issue still persists.

Here are packet capture logs.

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

I feel this is something related to DNS RRKEY Record size?

Plus then I dumbdb on my server and went through cache using command
#rndc dumpdb -all

And here is the output

incometax.gov.in<http://incometax.gov.in>.   3422NS  
ns01.incometax.gov.in<http://ns01.incometax.gov.in>.
3422NS  
ns02.incometax.gov.in<http://ns02.incometax.gov.in>.
ns01.incometax.gov.in<http://ns01.incometax.gov.in>.  131 \-  ;-$NXRRSET
; ns01.incometax.gov.in<http://ns01.incometax.gov.in>. RRSIG NSEC ...
; ns01.incometax.gov.in<http://ns01.incometax.gov.in>. NSEC 
ns02.incometax.gov.in<http://ns02.incometax.gov.in>. A RRSIG NSEC
; incometax.gov.in<http://incometax.gov.in>. SOA 
ns01.incometax.gov.in<http://ns01.incometax.gov.in>. 
ns-admin.cpc.incometax.gov.in<http://ns-admin.cpc.incometax.gov.in>. 2023060970 
7200 3600 1209600 3600
; incometax.gov.in<http://incometax.gov.in>. RRSIG SOA ...
ns02.incometax.gov.in<http://ns02.incometax.gov.in>.  120 \-  ;-$NXRRSET
; ns02.incometax.

Re: Facing issues while resolving only one record

[Greg Choules via bind-users]

Hi Blason.
"incometax.gov.in" is a domain known to cause problems. Take a binary
packet capture and look at it in Wireshark. Also see this
https://dnsviz.net/d/incometax.gov.in/dnssec/

A workaround in BIND is to disable DNSSEC validation for just that domain
whilst leaving it on generally: see below.
DNSSEC validation is on ("auto") by default these days. Please don't turn
it off for everything.

options {
...
validate-except {
incometax.gov.in;
...
};
...
};

Hope this helps.
Greg

On Wed, 30 Aug 2023 at 14:20, Blason R  wrote:

> Hi all,
>
> I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support
> Version)
> And I am facing this weird issue. Somehow eportal.incometax.gov.in site
> is not getting resolved through DNS.
>
> I tried a lot but unfortunately the issue still persists.
>
> Here are packet capture logs.
>
> listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length
> 262144 bytes
> 18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+
> A? eportal.incometax.gov.in. (42)
> 18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53:
> 30627+% [1au] A? eportal.incometax.gov.in. (65)
> 18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+
> ? eportal.incometax.gov.in. (42)
> 18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+%
> [1au] ? eportal.incometax.gov.in. (65)
> 18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53:
> 16204+% [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53:
> 34205+% [1au] ? eportal.incometax.gov.in. (65)
> 18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+
> A? eportal.incometax.gov.in. (42)
> 18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.205136 ens18 Out IP 192.168.1.133.33517 > 192.36.148.17.53: 18768
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53:
> 28883 [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.259888 ens18 Out IP 192.168.1.133.51762 > 59.160.103.171.53:
> 46716 [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.597312 ens18 In  IP 192.168.1.162.53963 > 192.168.1.133.53: 23+
> ? eportal.incometax.gov.in. (42)
> 18:47:26.498891 ens18 Out IP 192.168.1.133.52631 > 125.16.225.122.53:
> 12762 [1au] DNSKEY? incometax.gov.in. (57)
>
> I feel this is something related to DNS RRKEY Record size?
>
> Plus then I dumbdb on my server and went through cache using command
> *#rndc dumpdb -all*
>
> And here is the output
>
> incometax.gov.in.   3422NS  ns01.incometax.gov.in.
> 3422NS  ns02.incometax.gov.in.
> ns01.incometax.gov.in.  131 \-  ;-$NXRRSET
> ; ns01.incometax.gov.in. RRSIG NSEC ...
> ; ns01.incometax.gov.in. NSEC ns02.incometax.gov.in. A RRSIG NSEC
> ; incometax.gov.in. SOA ns01.incometax.gov.in.
> ns-admin.cpc.incometax.gov.in. 2023060970 7200 3600 1209600 3600
> ; incometax.gov.in. RRSIG SOA ...
> ns02.incometax.gov.in.  120 \-  ;-$NXRRSET
> ; ns02.incometax.gov.in. RRSIG NSEC ...
> ; ns02.incometax.gov.in. NSEC ns03.incometax.gov.in. A RRSIG NSEC
> ; incometax.gov.in. SOA ns02.incometax.gov.in.
> ns-admin.cpc.incometax.gov.in. 2023071447 7200 3600 1209600 3600
> ; incometax.gov.in. RRSIG SOA ...
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 130] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 119] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset

RE: Facing issues while resolving only one record

[John W. Blue via bind-users]

Recommend you turn off DNSSEC validation and see if it starts working.

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

John

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

Hi all,

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

I tried a lot but unfortunately the issue still persists.

Here are packet capture logs.

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

I feel this is something related to DNS RRKEY Record size?

Plus then I dumbdb on my server and went through cache using command
#rndc dumpdb -all

And here is the output

incometax.gov.in<http://incometax.gov.in>.   3422NS  
ns01.incometax.gov.in<http://ns01.incometax.gov.in>.
3422NS  
ns02.incometax.gov.in<http://ns02.incometax.gov.in>.
ns01.incometax.gov.in<http://ns01.incometax.gov.in>.  131 \-  ;-$NXRRSET
; ns01.incometax.gov.in<http://ns01.incometax.gov.in>. RRSIG NSEC ...
; ns01.incometax.gov.in<http://ns01.incometax.gov.in>. NSEC 
ns02.incometax.gov.in<http://ns02.incometax.gov.in>. A RRSIG NSEC
; incometax.gov.in<http://incometax.gov.in>. SOA 
ns01.incometax.gov.in<http://ns01.incometax.gov.in>. 
ns-admin.cpc.incometax.gov.in<http://ns-admin.cpc.incometax.gov.in>. 2023060970 
7200 3600 1209600 3600
; incometax.gov.in<http://incometax.gov.in>. RRSIG SOA ...
ns02.incometax.gov.in<http://ns02.incometax.gov.in>.  120 \-  ;-$NXRRSET
; ns02.incometax.gov.in<http://ns02.incometax.gov.in>. RRSIG NSEC ...
; ns02.incometax.gov.in<http://ns02.incometax.gov.in>. NSEC 
ns03.incometax.gov.in<http://ns03.incometax.gov.in>. A RRSIG NSEC
; incometax.gov.in<http://incometax.gov.in>. SOA 
ns02.incometax.gov.in<http://ns02.incometax.gov.in>. 
ns-admin.cpc.incometax.gov.in<http://ns-admin.cpc.incometax.gov.in>. 2023071447 
7200 3600 1209600 3600
; incometax.gov.in<http://incometax.gov.in>. RRSIG SOA ...
; ns01.incometax.gov.in<http://ns01.incometax.gov.in> [v6 TTL 131] [v4 
unexpected] [v6 nxrrset]
; ns02.incometax.gov.in<http://ns02.incometax.gov.in> [v6 TTL 120] [v4 
unexpected] [v6 nxrrset]
; ns01.incometax.gov.

Facing issues while resolving only one record

[Blason R]

Hi all,

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

I tried a lot but unfortunately the issue still persists.

Here are packet capture logs.

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

I feel this is something related to DNS RRKEY Record size?

Plus then I dumbdb on my server and went through cache using command
*#rndc dumpdb -all*

And here is the output

incometax.gov.in.   3422NS  ns01.incometax.gov.in.
3422NS  ns02.incometax.gov.in.
ns01.incometax.gov.in.  131 \-  ;-$NXRRSET
; ns01.incometax.gov.in. RRSIG NSEC ...
; ns01.incometax.gov.in. NSEC ns02.incometax.gov.in. A RRSIG NSEC
; incometax.gov.in. SOA ns01.incometax.gov.in. ns-admin.cpc.incometax.gov.in.
2023060970 7200 3600 1209600 3600
; incometax.gov.in. RRSIG SOA ...
ns02.incometax.gov.in.  120 \-  ;-$NXRRSET
; ns02.incometax.gov.in. RRSIG NSEC ...
; ns02.incometax.gov.in. NSEC ns03.incometax.gov.in. A RRSIG NSEC
; incometax.gov.in. SOA ns02.incometax.gov.in. ns-admin.cpc.incometax.gov.in.
2023071447 7200 3600 1209600 3600
; incometax.gov.in. RRSIG SOA ...
; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 130] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 119] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset]
; ns01.incometax.gov.in 

Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

[OwN-3m-All]

Ok, I fixed the problem.

I changed the zonefile templates for dynamic DNS used at dynamix.run to the
following:
$TTL60
@   IN  SOA ns.{domainname}. ad...@dynamix.run (
{serial} ;
30   ; Refresh
20; Retry
1209600  ; Expire
30 ) ; Minimum

{domainname}.   IN NS   ns.{domainname}.
ns.{domainname}.IN A{serverip}
ns.{domainname}.IN A{serveripBackup}

Rather than:

$TTL60
@   IN  SOA ns.{domainname}. ad...@dynamix.run (
{serial} ;
30   ; Refresh
20; Retry
1209600  ; Expire
30 ) ; Minimum

{domainname}.   IN NS   ns.{domainname}.
ns.{domainname}.IN A{dnsip}

{dnsip} would get updated with the user's dynamic IP address.  Thus, if you
were to query specific.wildcard-test.dynx.me, it would send the traffic to
their IP address to resolve, which is not correct, since the record is
defined on the main server, not theirs.

This makes it so queries for that subdomain resolve to that same specific
server, rather than the IP address provided by the end user since it is
acting as the main DNS server, in this case.

But, it still makes no sense to me how google's DNS (and others) was able
to resolve everything just fine... google's dns must not be asking
ns.{domainname}. for the records?

How crazy.  I still don't fully understand why this happens, but I could
clearly see tcpdump asking 23.29.117.19 for the A record for
specific.wildcard-test.dynx.me which it has no information about since
there is no zonefile on 23.29.117.19 for wildcard-test.dynx.me...
-- 
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 to Bind DNS Lookup - Returns wildcard value for defined A record

[OwN-3m-All]

I turned logging on, but I'm still not seeing anything that can help me
pinpoint why the query is failing?

Audit log:

18-Jul-2023 19:45:14.938 client @0x7f26e6def368 23.29.117.19#44526 (*.
wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV
(23.29.117.19)
18-Jul-2023 19:45:22.142 client @0x7f26e6dee568 73.95.58.29#42969 (*.
wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A +E(0)K
(23.29.117.19)
18-Jul-2023 19:45:22.142 fetch: *.wildcard-test.dynx.me/A
18-Jul-2023 19:45:22.142 client @0x7f26e6def368 23.29.117.19#47048 (*.
wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV
(23.29.117.19)
18-Jul-2023 19:45:23.678 client @0x7f26e6dee568 73.95.58.29#57458 (*.
wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A +E(0)K
(23.29.117.19)
18-Jul-2023 19:45:23.678 fetch: *.wildcard-test.dynx.me/A
18-Jul-2023 19:45:23.678 client @0x7f26e6def368 23.29.117.19#42309 (*.
wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV
(23.29.117.19)
18-Jul-2023 19:45:33.762 client @0x7f26e6dee568 73.95.58.29#59621 (*.
wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A +E(0)K
(23.29.117.19)
18-Jul-2023 19:45:33.762 fetch: *.wildcard-test.dynx.me/A
18-Jul-2023 19:45:33.762 client @0x7f26e6def368 23.29.117.19#33868 (*.
wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV
(23.29.117.19)
18-Jul-2023 19:45:58.579 client @0x7f26e6dee568 73.95.58.29#54464 (
wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A +E(0)K
(23.29.117.19)
18-Jul-2023 19:45:58.579 fetch: wildcard-test.dynx.me/A
18-Jul-2023 19:45:58.579 client @0x7f26e6def368 23.29.117.19#37135 (
wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A -E(0)DCV
(23.29.117.19)
18-Jul-2023 19:45:58.579 fetch: ns.wildcard-test.dynx.me/
18-Jul-2023 19:46:03.727 client @0x7f26e6dee568 73.95.58.29#54348 (
wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A +E(0)K
(23.29.117.19)
18-Jul-2023 19:46:03.727 fetch: wildcard-test.dynx.me/A
18-Jul-2023 19:46:03.727 client @0x7f26e6def368 23.29.117.19#51242 (
wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A -E(0)DCV
(23.29.117.19)
18-Jul-2023 19:46:14.143 client @0x7f26e6dee568 73.95.58.29#43180 (
specific.wildcard-test.dynx.me): query: specific.wildcard-test.dynx.me IN A
+E(0)K (23.29.117.19)
18-Jul-2023 19:46:14.143 fetch: specific.wildcard-test.dynx.me/A
18-Jul-2023 19:46:14.143 fetch: _.wildcard-test.dynx.me/A
18-Jul-2023 19:46:14.183 client @0x7f26e6def368 23.29.117.19#59351 (
specific.wildcard-test.dynx.me): query: specific.wildcard-test.dynx.me IN A
-E(0)DCV (23.29.117.19)

Query log:

client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58627 (
wildcard-test.dynx.me): query failed (failure) for
wildcard-test.dynx.me/IN/ at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58635 (
specific.wildcard-test.dynx.me): query failed (failure) for
specific.wildcard-test.dynx.me/IN/A at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58636 (
specific.wildcard-test.dynx.me): query failed (failure) for
specific.wildcard-test.dynx.me/IN/ at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58644 (
specific.wildcard-test.dynx.me): query failed (failure) for
specific.wildcard-test.dynx.me/IN/A at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58645 (
specific.wildcard-test.dynx.me): query failed (failure) for
specific.wildcard-test.dynx.me/IN/ at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58653 (
specific.wildcard-test.dynx.me): query failed (failure) for
specific.wildcard-test.dynx.me/IN/A at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58654 (
specific.wildcard-test.dynx.me): query failed (failure) for
specific.wildcard-test.dynx.me/IN/ at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58662 (
specific.wildcard-test.dynx.me): query failed (SERVFAIL) for
specific.wildcard-test.dynx.me/IN/A at query.c:7094
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58663 (
specific.wildcard-test.dynx.me): query failed (SERVFAIL) for
specific.wildcard-test.dynx.me/IN/ at query.c:7094
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58672 (
wildcard-test.dynx.me): query failed (failure) for
wildcard-test.dynx.me/IN/ at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58681 (
wildcard-test.dynx.me): query failed (failure) for
wildcard-test.dynx.me/IN/ at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58690 (
wildcard-test.dynx.me): query failed (failure) for
wildcard-test.dynx.me/IN/ at query.c:7824
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58699 (
wildcard-test.dynx.me): query failed (SERVFAIL) for
wildcard-test.dynx.me/IN/ at query.c:7094
client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58707 (

Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

[OwN-3m-All]

The output from "named-checkconf -px" is over a million lines long, but
here you go:

http://23.29.117.19/bindconf.zip

My resolver servers are setup for ad-blocking, hence why there are so many
defined zones.

Here is a quick tcpdump sample where I do not see anything too helpful:

http://23.29.117.19/bind_tcpdump.zip
-- 
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 to Bind DNS Lookup - Returns wildcard value for defined A record

[Greg Choules via bind-users]

This time from the correct email alias!

On Mon, 17 Jul 2023 at 22:58, Greg Choules 
wrote:

> Hi.
> Some observations:
> - Please don't use nslookup. Please use dig, it is much more versatile and
> gives much more information with which to try and interpret what might be
> going on.
> - If you're going to specify a destination server please use its IP
> address, not its domain name (dnsr.dinofly.com). The reason for this is
> that if you use a domain, first that domain needs to be resolved to an IP
> address by the OS, which may or may not work, or may not give the result
> you were expecting.
> - I did a dig for "specific.wildcard-test.dynx.me" against my own BIND
> server and it resolved to 1.1.1.1. So the issue is with your resolver. This
> is not new, just confirming that this must be the problem end, not the auth
> end.
> - Please paste *the entire* config of your resolver, not just bits
> that you think might be important. "named-checkconf -px" will produce that.
> - Please run tcpdump on your resolver for port 53, captured to disc, then
> download and analyse it in Wireshark. Only by seeing what your server does
> after it receives your dig will you understand how it is attempting to find
> an answer, which should shed some light on why you get the response you do.
> That is, if you DO get the same answer using dig (@IP) rather than nslookup
> (at domain).
>
> Cheers, Greg
>
> On Mon, 17 Jul 2023 at 20:36, OwN-3m-All  wrote:
>
>> Spam assassin is blocking my message, so here are all the details (my
>> latest response message):
>>
>> https://pastebin.com/raw/jSm6aGfC
>> --
>> 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: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

[OwN-3m-All]

Spam assassin is blocking my message, so here are all the details (my
latest response message):

https://pastebin.com/raw/jSm6aGfC
-- 
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 to Bind DNS Lookup - Returns wildcard value for defined A record

[Ondřej Surý]

Also:- make the record self-contained, don’t make us go elsewhere, especially not to a place where data could disappear at the whim of the owner (as seen recently)- and finally, describe what you see, don’t speculate what it might be; by describing you are less likely to miss an important detailOndř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 16. 7. 2023, at 10:25, Greg Choules via bind-users  wrote:Real data please:- example queries (genuine, not invented for illustration)- real domains- real IP addresses- packet captures- both BIND server configs- zone file contents- startup logsThere are so many things it *could* be, the more information the better.Cheers, GregOn Sun, 16 Jul 2023 at 09:09, OwN-3m-All <own3m...@gmail.com> wrote:I've got a bind recursion DNS server setup that is returning the wrong value for an outside domain that I also maintain and host on another server running a bind DNS server.  Yet Google's DNS and other major DNS providers respond with the correct IP address A record when querying.  I can't figure out why my recursion enabled instance is not returning the correct IP address for a specific host.  Rather, it returns the wildcard value from the zonefile rather than the specifically specified A record entry created for that host.  It appears bind to bind is returning the wildcard value for a specifically defined host in the zonefile from the server it's hosted on.Is this a recent bug in bind?  More information about my setup and issue can be found here:https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entrFrom what I found online, if there's a specific host A record entry defined, it should always return that IP.  Wildcard is only for those not defined.  Yet, when I remove the wildcard from the zonefile, my bind recursion instance returns the correct value, but not when the wildcard entry is there.  But Google and other major DNS providers return the non-wildcard value as expected.Any help is appreciated.
-- 
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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

[Greg Choules via bind-users]

Real data please:
- example queries (genuine, not invented for illustration)
- real domains
- real IP addresses
- packet captures
- both BIND server configs
- zone file contents
- startup logs

There are so many things it *could* be, the more information the better.

Cheers, Greg

On Sun, 16 Jul 2023 at 09:09, OwN-3m-All  wrote:

> I've got a bind recursion DNS server setup that is returning the wrong
> value for an outside domain that I also maintain and host on another server
> running a bind DNS server.  Yet Google's DNS and other major DNS providers
> respond with the correct IP address A record when querying.  I can't figure
> out why my recursion enabled instance is not returning the correct IP
> address for a specific host.  Rather, it returns the wildcard value from
> the zonefile rather than the specifically specified A record entry created
> for that host.
>
> It appears bind to bind is returning the wildcard value for a specifically
> defined host in the zonefile from the server it's hosted on.
>
> Is this a recent bug in bind?  More information about my setup and issue
> can be found here:
>
>
> https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr
>
> From what I found online, if there's a specific host A record entry
> defined, it should always return that IP.  Wildcard is only for those not
> defined.  Yet, when I remove the wildcard from the zonefile, my bind
> recursion instance returns the correct value, but not when the wildcard
> entry is there.  But Google and other major DNS providers return the
> non-wildcard value as expected.
>
> Any help is appreciated.
> --
> 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: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

[Matus UHLAR - fantomas]

On 16.07.23 02:08, OwN-3m-All wrote:

I've got a bind recursion DNS server setup that is returning the wrong
value for an outside domain that I also maintain and host on another server
running a bind DNS server.  Yet Google's DNS and other major DNS providers
respond with the correct IP address A record when querying.  I can't figure
out why my recursion enabled instance is not returning the correct IP
address for a specific host.  Rather, it returns the wildcard value from
the zonefile rather than the specifically specified A record entry created
for that host.

It appears bind to bind is returning the wildcard value for a specifically
defined host in the zonefile from the server it's hosted on.

Is this a recent bug in bind?  More information about my setup and issue
can be found here:

https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr

From what I found online, if there's a specific host A record entry
defined, it should always return that IP.  Wildcard is only for those not
defined.  Yet, when I remove the wildcard from the zonefile, my bind
recursion instance returns the correct value, but not when the wildcard
entry is there.  But Google and other major DNS providers return the
non-wildcard value as expected.


Please provide concrete example, I can't query fun.test.test.me. nor 
test.test.me.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
--
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

Bind to Bind DNS Lookup - Returns wildcard value for defined A record

[OwN-3m-All]

I've got a bind recursion DNS server setup that is returning the wrong
value for an outside domain that I also maintain and host on another server
running a bind DNS server.  Yet Google's DNS and other major DNS providers
respond with the correct IP address A record when querying.  I can't figure
out why my recursion enabled instance is not returning the correct IP
address for a specific host.  Rather, it returns the wildcard value from
the zonefile rather than the specifically specified A record entry created
for that host.

It appears bind to bind is returning the wildcard value for a specifically
defined host in the zonefile from the server it's hosted on.

Is this a recent bug in bind?  More information about my setup and issue
can be found here:

https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr

>From what I found online, if there's a specific host A record entry
defined, it should always return that IP.  Wildcard is only for those not
defined.  Yet, when I remove the wildcard from the zonefile, my bind
recursion instance returns the correct value, but not when the wildcard
entry is there.  But Google and other major DNS providers return the
non-wildcard value as expected.

Any help is appreciated.
-- 
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[Matthijs Mekking]

On 24-10-2022 15:14, PGNet Dev wrote:

The good news it is not stuck.


What indicator flags that it IS 'stuck'?  Is it explicitly logged?


Because the keymgr logs says it is just waiting time?

2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT (wait 93600 seconds)



BIND is waiting to make sure the new DS is also known to the 
validators. The time being evaluated here is the DS TTL, plus 
parent-propagation-delay, plus retire-safety. All these three values 
are configurable within dnssec-policy.


my current config has

 parent-ds-ttl  PT1H;
 parent-propagation-delay   PT1H;
 retire-safety  PT1H;

@ parental-agents, the DS is cached; ttl appears spec'd other than my 
set ttl. e.g., @ cloudflare, it's 1 day ...


in any case, all of my domains still returned "DSState: rumoured" at < 4 
days.
since then, about 1/4 of the domains have flipped from "rumoured" -> 
"omnipresent", with no manual intervention; the rest are still unchanged.


again, i've noticed no actual operational problems -- e.g., queries 
failing, etc -- other than these delays.


seems, tho, i've still got a likely misconfig somewhere in here.


I am happy to look into it, if you are willing to share the key 
**state** file in question (off-list), and dnssec-policy configuration.


A full excerpt of the debug logs around 2022-10-21T16:55:22 can also be 
useful.


Best regards,

Matthijs
--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

The good news it is not stuck.


What indicator flags that it IS 'stuck'?  Is it explicitly logged?


BIND is waiting to make sure the new DS is also known to the validators. The 
time being evaluated here is the DS TTL, plus parent-propagation-delay, plus 
retire-safety. All these three values are configurable within dnssec-policy.


my current config has

parent-ds-ttl  PT1H;
parent-propagation-delay   PT1H;
retire-safety  PT1H;

@ parental-agents, the DS is cached; ttl appears spec'd other than my set ttl. 
e.g., @ cloudflare, it's 1 day ...

in any case, all of my domains still returned "DSState: rumoured" at < 4 days.
since then, about 1/4 of the domains have flipped from "rumoured" -> 
"omnipresent", with no manual intervention; the rest are still unchanged.

again, i've noticed no actual operational problems -- e.g., queries failing, 
etc -- other than these delays.

seems, tho, i've still got a likely misconfig somewhere in here.



--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[Matthijs Mekking]

Hi,

On 21-10-2022 23:05, PGNet Dev wrote:

I exec

 rndc dnssec -checkds -key 63917 published example.com IN external


with dnssec loglevel -> debug, on exec, in logs

   2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/63917 type DS in state RUMOURED
   2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT?
   2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) 
rule2=(~true or true) rule3=(~false or false)
   2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT (wait 93600 seconds)


which certainly looks like a 'no'

reason is "time says no", after "dnssec evaluation".

which time is being evaluated here?


The good news it is not stuck. BIND is waiting to make sure the new DS 
is also known to the validators. The time being evaluated here is the DS 
TTL, plus parent-propagation-delay, plus retire-safety. All these three 
values are configurable within dnssec-policy.


Best regards,

Matthijs
--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

I exec

 rndc dnssec -checkds -key 63917 published example.com IN external


with dnssec loglevel -> debug, on exec, in logs

  2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: examine KSK example.com/ECDSAP256SHA256/63917 type DS 
in state RUMOURED
  2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state OMNIPRESENT?
  2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) rule2=(~true 
or true) rule3=(~false or false)
  2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: time says no to KSK example.com/ECDSAP256SHA256/63917 
type DS state RUMOURED to state OMNIPRESENT (wait 93600 seconds)

which certainly looks like a 'no'

reason is "time says no", after "dnssec evaluation".

which time is being evaluated here?
--
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

after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

with bind 9.18, config'd for dnssec-policy automated signing, I've a dnssec 
signed zone,

rndc dnssec -status example.com IN external
dnssec-policy: test
current time:  Fri Oct 21 16:14:06 2022

key: 47219 (ECDSAP256SHA256), ZSK
  published:  yes - since Fri Oct 21 15:22:27 2022
  zone signing:   yes - since Fri Oct 21 17:27:27 2022

  Next rollover scheduled on Thu Jan 19 14:22:27 2023
  - goal:   omnipresent
  - dnskey: rumoured
  - zone rrsig: rumoured

key: 63917 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  key signing:yes - since Sat Oct 15 15:52:05 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: rumoured
  - key rrsig:  omnipresent

key: 43175 (ECDSAP256SHA256), ZSK
  published:  no
  zone signing:   no

  Key has been removed from the zone
  - goal:   hidden
  - dnskey: unretentive
  - zone rrsig: unretentive


note for the KSK, it's ds state,

  - ds: rumoured

I've verified externally that thhe zone's DS RECORD has been pushed to 
registrar->parent, it's fully propagated, and is passing all the 
external/online checks.

reading @ https://kb.isc.org/docs/dnssec-key-and-signing-policy

"Note: If you see the DSState stuck in rumoured after the migration, you 
need to run rndc dnssec -checkds published example.com to tell BIND that the DS is 
already published in the parent zone"

I exec

rndc dnssec -checkds -key 63917 published example.com IN external
KSK 63917: Marked DS as published since 21-Oct-2022 16:19:36.000

rndc reload
server reload successful

and check again,

rndc dnssec -status example.com IN external
...
key: 63917 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  key signing:yes - since Sat Oct 15 15:52:05 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
!!- ds: rumoured
  - key rrsig:  omnipresent
...

grep DSState  Kexample.com.+013+63917.state
!!  DSState: rumoured

ds state is still just "rumoured".

What additional steps are needed to update that DSState correctly?
--
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: Can't modify an existing SPF record

[Roberto Carna]

Ok now I understand.thanks a lot to you!

El vie, 8 jul 2022 a las 19:58, Greg Choules
() escribió:
>
> The SPF record type was deprecated in 2014 and the SPF definition string 
> *must* now be contained as data in a TXT record.
> BIND will still load a zone containing SPF records, but it will check whether 
> a TXT record also exists that contains the same string and will generate a 
> log message telling you if it doesn't find one.
>
> From a quick glance at the webmin manual it *should* allow you to put 
> anything you like in a TXT record.
> @Roberto Carna  your SPF record currently looks like this:
>
> company.com. 971 IN TXT "v=spf1 mx ip4:[corpIP] include:mktomail.com ~all"
>
>
> The ip4:[corpIP] will not work. [] are not valid characters in the SPF 
> specification and in any case ip4: must be followed by a literal dotted 
> decimal IPv4 address.
>
> On Fri, 8 Jul 2022 at 17:34, Benny Pedersen  wrote:
>>
>> On 2022-07-08 18:14, Crist Clark wrote:
>> > As far as BIND is concerned, this is arbitrary text in a TXT record.
>> > It doesn’t know or care about SPF syntax within it.
>>
>> TXT records is mostly used, and SPF records is in bind supported
>> --
>> 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: Can't modify an existing SPF record

[Greg Choules via bind-users]

The SPF record type was deprecated in 2014 and the SPF definition string
*must* now be contained as data in a TXT record.
BIND will still load a zone containing SPF records, but it will check
whether a TXT record also exists that contains the same string and will
generate a log message telling you if it doesn't find one.

>From a quick glance at the webmin manual it *should* allow you to put
anything you like in a TXT record.
@Roberto Carna   your SPF record currently looks
like this:

company.com. 971 IN TXT "v=spf1 mx ip4:[corpIP] include:mktomail.com ~all"


The ip4:[corpIP] will not work. [] are not valid characters in the SPF
specification and in any case ip4: must be followed by a literal dotted
decimal IPv4 address.

On Fri, 8 Jul 2022 at 17:34, Benny Pedersen  wrote:

> On 2022-07-08 18:14, Crist Clark wrote:
> > As far as BIND is concerned, this is arbitrary text in a TXT record.
> > It doesn’t know or care about SPF syntax within it.
>
> TXT records is mostly used, and SPF records is in bind supported
> --
> 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: Can't modify an existing SPF record

[Benny Pedersen]

On 2022-07-08 18:14, Crist Clark wrote:

As far as BIND is concerned, this is arbitrary text in a TXT record.
It doesn’t know or care about SPF syntax within it.


TXT records is mostly used, and SPF records is in bind supported
--
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: Can't modify an existing SPF record

[Benny Pedersen]

On 2022-07-08 18:04, Roberto Carna wrote:

Dear all, I add "a:relay.company.com" using the CLI in the BIND master:

company.com. 3600IN  TXT "v=spf1 mx a:relay.company.com 
-all"


But after restart, this change never goes to the slaves.

If I add "ip:x.x.x.x" for example, this change goes ok to the slaves.


ip: is invalid

ip4: is valid :)
ip6: is valid

and lastly a: includes ip6 on the hostnames

And from webmin interface, if I add the "a:relay.company.com" I get 
this error:

Failed to save record : 'relay.company.com' is not a valid host to
allow sending from


stupid webmin

check spf here https://www.kitterman.com/spf/validate.html
--
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: Can't modify an existing SPF record

[Roberto Carna]

Thanks a lot, it's a webmin interface error because it doesn't accept
characters in allowed host sender option.

Sorry for my interruption.

Greetings !!!

El vie, 8 jul 2022 a las 13:14, Crist Clark
() escribió:
>
> As far as BIND is concerned, this is arbitrary text in a TXT record. It 
> doesn’t know or care about SPF syntax within it.
>
> It sounds like you’re having webmin problems, not BIND.
>
> On Fri, Jul 8, 2022 at 9:08 AM Ondřej Surý  wrote:
>>
>>
>> > On 8. 7. 2022, at 18:05, Roberto Carna  wrote:
>> >
>> > using the CLI in the BIND master
>>
>> What does this mean and how exactly are you changing the zone? List all the 
>> steps that you are doing when changing the zone contents.
>>
>> Ondrej
>> --
>> 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.
>>
>> --
>> 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: Can't modify an existing SPF record

[Matus UHLAR - fantomas]

On 08.07.22 13:04, Roberto Carna wrote:

Dear all, I add "a:relay.company.com" using the CLI in the BIND master:

company.com. 3600IN  TXT "v=spf1 mx a:relay.company.com -all"

But after restart, this change never goes to the slaves.

If I add "ip:x.x.x.x" for example, this change goes ok to the slaves.

And from webmin interface, if I add the "a:relay.company.com" I get this error:

Failed to save record : 'relay.company.com' is not a valid host to
allow sending from


relay.company.com does not exist:

% host -t a relay.company.com
relay.company.com has no A record
% host -t  relay.company.com
relay.company.com has no  record

you must add a host that does exist.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory.
--
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: Can't modify an existing SPF record

[Crist Clark]

As far as BIND is concerned, this is arbitrary text in a TXT record. It
doesn’t know or care about SPF syntax within it.

It sounds like you’re having webmin problems, not BIND.

On Fri, Jul 8, 2022 at 9:08 AM Ondřej Surý  wrote:

>
> > On 8. 7. 2022, at 18:05, Roberto Carna  wrote:
> >
> > using the CLI in the BIND master
>
> What does this mean and how exactly are you changing the zone? List all
> the steps that you are doing when changing the zone contents.
>
> Ondrej
> --
> 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.
>
> --
> 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: Can't modify an existing SPF record

[Ondřej Surý]

> On 8. 7. 2022, at 18:05, Roberto Carna  wrote:
> 
> using the CLI in the BIND master

What does this mean and how exactly are you changing the zone? List all the 
steps that you are doing when changing the zone contents.

Ondrej
--
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.

-- 
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: Can't modify an existing SPF record

[Roberto Carna]

Dear all, I add "a:relay.company.com" using the CLI in the BIND master:

company.com. 3600IN  TXT "v=spf1 mx a:relay.company.com -all"

But after restart, this change never goes to the slaves.

If I add "ip:x.x.x.x" for example, this change goes ok to the slaves.

And from webmin interface, if I add the "a:relay.company.com" I get this error:

Failed to save record : 'relay.company.com' is not a valid host to
allow sending from

I suspect the problem is with additional hostnames..I don't know.

Thanks again!

El vie, 8 jul 2022 a las 12:55, Richard T.A. Neal
() escribió:
>
> Hi Roberto,
>
>
>
> You need to prefix it with “a:” to indicate that this is an A-record, i.e.:
>
>
>
> a:relay.company.com
>
>
>
> Best,
>
>
>
> Richard.
>
>
>
> From: bind-users  On Behalf Of Greg Choules 
> via bind-users
> Sent: 08 July 2022 4:45 pm
> To: Roberto Carna 
> Cc: ML BIND Users 
> Subject: Re: Can't modify an existing SPF record
>
>
>
> Hi Roberto. What domain is this SPF for and exactly how are you trying to add 
> the extra term?
>
> Cheers, Greg
>
>
>
> On Fri, 8 Jul 2022 at 16:38, Roberto Carna  wrote:
>
> Dear, from my webmin interface for BIND9, I try to add an additional
> allowed sender host to our SPF record, but I get the following error:
>
> Failed to save record : 'relay.company.com' is not a valid host to
> allow sending from
>
> What does this mean? Do I have to consider some important thing I'm 
> forgetting ?
>
> relay.company.com is already defined in our public DNS, and it has a
> reverse record too.
>
> if I add this record by hand, it's not replicated to the DNS slaves.
>
> Thanks in advance!!!
> --
> 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: Can't modify an existing SPF record

[Mark Elkins]

There can only be one SFP TXT record per domain. A complete record could 
look like.


domain1.com.  IN    TXT   "v=spf1 a:mail.domain1.com 
a:smtp.domain1.com a:relay.domain2.com -all"


It should be logical to use a (domain) name because that name could have 
multiple IP addresses, both IPv4 and IPv6.

Note that there are double quotes around the whole TXT string as well.

On 7/8/22 5:55 PM, Richard T.A. Neal wrote:


Hi Roberto,

You need to prefix it with “a:” to indicate that this is an A-record, 
i.e.:


a:relay.company.com

Best,

Richard.

*From:*bind-users  *On Behalf Of 
*Greg Choules via bind-users

*Sent:* 08 July 2022 4:45 pm
*To:* Roberto Carna 
*Cc:* ML BIND Users 
*Subject:* Re: Can't modify an existing SPF record

Hi Roberto. What domain is this SPF for and exactly how are you trying 
to add the extra term?


Cheers, Greg

On Fri, 8 Jul 2022 at 16:38, Roberto Carna <mailto:robertocarn...@gmail.com>> wrote:


Dear, from my webmin interface for BIND9, I try to add an additional
allowed sender host to our SPF record, but I get the following error:

Failed to save record : 'relay.company.com
<http://relay.company.com>' is not a valid host to
allow sending from

What does this mean? Do I have to consider some important thing
I'm forgetting ?

relay.company.com <http://relay.company.com> is already defined in
our public DNS, and it has a
reverse record too.

if I add this record by hand, it's not replicated to the DNS slaves.

Thanks in advance!!!
-- 
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>



--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 
<https://ftth.posix.co.za>


Posix SystemsVCARD for MJ Elkins

-- 
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: Can't modify an existing SPF record

[Richard T.A. Neal]

Hi Roberto,

You need to prefix it with “a:” to indicate that this is an A-record, i.e.:

a:relay.company.com

Best,

Richard.

From: bind-users  On Behalf Of Greg Choules 
via bind-users
Sent: 08 July 2022 4:45 pm
To: Roberto Carna 
Cc: ML BIND Users 
Subject: Re: Can't modify an existing SPF record

Hi Roberto. What domain is this SPF for and exactly how are you trying to add 
the extra term?
Cheers, Greg

On Fri, 8 Jul 2022 at 16:38, Roberto Carna 
mailto:robertocarn...@gmail.com>> wrote:
Dear, from my webmin interface for BIND9, I try to add an additional
allowed sender host to our SPF record, but I get the following error:

Failed to save record : 'relay.company.com<http://relay.company.com>' is not a 
valid host to
allow sending from

What does this mean? Do I have to consider some important thing I'm forgetting ?

relay.company.com<http://relay.company.com> is already defined in our public 
DNS, and it has a
reverse record too.

if I add this record by hand, it's not replicated to the DNS slaves.

Thanks in advance!!!
--
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<mailto: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: Can't modify an existing SPF record

[Greg Choules via bind-users]

Hi Roberto. What domain is this SPF for and exactly how are you trying to
add the extra term?
Cheers, Greg

On Fri, 8 Jul 2022 at 16:38, Roberto Carna  wrote:

> Dear, from my webmin interface for BIND9, I try to add an additional
> allowed sender host to our SPF record, but I get the following error:
>
> Failed to save record : 'relay.company.com' is not a valid host to
> allow sending from
>
> What does this mean? Do I have to consider some important thing I'm
> forgetting ?
>
> relay.company.com is already defined in our public DNS, and it has a
> reverse record too.
>
> if I add this record by hand, it's not replicated to the DNS slaves.
>
> Thanks in advance!!!
> --
> 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

Can't modify an existing SPF record

[Roberto Carna]

Dear, from my webmin interface for BIND9, I try to add an additional
allowed sender host to our SPF record, but I get the following error:

Failed to save record : 'relay.company.com' is not a valid host to
allow sending from

What does this mean? Do I have to consider some important thing I'm forgetting ?

relay.company.com is already defined in our public DNS, and it has a
reverse record too.

if I add this record by hand, it's not replicated to the DNS slaves.

Thanks in advance!!!
-- 
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: Delete/update MX record

[Jan-Piet Mens via bind-users]

Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.


REFUSED is also reported when attempting to update a non-dynamic zone. Are you 
sure the zone you're trying to update is actually dynamic?


How do I remove and replace the MX record for a domain with nsupdate?


del ownernamne. MX [rdata]

should do it. Without [rdata] all MX for the owner will be removed, but specify 
rdata to indicate you wish to delete just the one.

As Mark said: best demonstrate what you are doing.

-JP

--
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: Delete/update MX record

[Tony Finch]

@lbutlr  wrote:

> Using nsupdate when I try to delete an MX record for a domain, I get
> REFSUED.
>
> When I try to add an MX record with the same priority (or not), it
> leaves the old record as well.
>
> How do I remove and replace the MX record for a domain with nsupdate?

The UPDATE protocol will not tell the client why it didn't work; for that
you must check `named`s logs.

In general, with UPDATE it's best to delete then add records for a name,
using a single UPDATE transaction to avoid any point in time where the
name is missing. The comments in nsdiff say:

# For each owner name prepare deletion commands followed by addition
# commands. This ensures TTL adjustments and CNAME/other replacements
# are handled correctly. Ensure each owner's changes are not split below.

There's are a couple of cases where this doesn't work: the SOA and NS
RRsets. For SOA, you can just add the new record which implicitly replaces
the old one. For NS records, in my experience complete replacement is rare
enough that it's OK to simply nspatch the zone twice. (The NS delete will
be ignored instead of rejected.)

-- 
Tony Finch(he/they)  Cambridge, England
Shetland Isles: Variable 3 or less, becoming north or northeast 3 or 4
later. Slight, but smooth in southeast. Mainly fair. Good.
-- 
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: Delete/update MX record

[Mark Andrews]

Show your procedure. 

-- 
Mark Andrews

> On 5 Jun 2022, at 06:37, @lbutlr  wrote:
> 
> Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.
> 
> When I try to add an MX record with the same priority (or not), it leaves the 
> old record as well.
> 
> How do I remove and replace the MX record for a domain with nsupdate?
> 
> -- 
> A woman stays up all night with two men
>(Singin' in the Rain)
> 
> -- 
> 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

Delete/update MX record

[@lbutlr]

Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.

When I try to add an MX record with the same priority (or not), it leaves the 
old record as well.

How do I remove and replace the MX record for a domain with nsupdate?

-- 
A woman stays up all night with two men
(Singin' in the Rain)

-- 
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: per record responses based on originating IP

[Angus Clarke]

Hello

I found that knot's geoip module can modify responses to individual records 
based on the source address of the client through the module's "net" directive 
and have successfully tested the modification of NS responses based on the 
client's source subnet - it seems to do exactly what I want.

I had a quick check of the bind geoip module but the example given in the 
documentation suggests presenting an entire zone as an alternative view.

Thanks for taking the time with me on my quest, but I think I'll further 
investigate knot at this time.

knot geoip module overview:
https://blog.apnic.net/2018/11/14/geoip-in-knot-dns-2-7/

Thanks
Angus


From: bind-users  on behalf of Nick Tait via 
bind-users 
Sent: 16 May 2022 13:55
To: BIND Users Mailing List 
Subject: Re: per record responses based on originating IP

On 16/05/22 20:05, Angus Clarke wrote:
As mentioned in a separate reply to Grant, the goal is to have (amongst other 
things) local recursors "find" the locally deployed authoritative servers 
through NS records. What hasn't been mentioned is that I am also looking to 
simplify configuration management by means of a single set of data which can be 
deployed to all authoritative servers - I don't think the RPZ solution proposed 
by Nick achieves that.

That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.

Hi Angus.

Thanks for clarifying. Based on what you've said, what I proposed probably has 
slightly more merit than I concluded, although admittedly it doesn't quite tick 
all the boxes...

Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are represented as 
prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I was specifying a 
single host which is why the RPZ-CLIENT-IP records all started with 32.

Secondly, RPZs are more commonly used on recursive resolvers rather than the 
authoritative nameservers for the zone, although in your case if you are 
wanting to change the answer that an authoritative nameserver gives to the NS 
question from the recursive resolver, then it probably makes the most sense to 
put the RPZ on the authoritative nameserver. In this case you'd also need to 
specify "recursive-only no". (FYI Default behaviour is to apply RPZ rewriting 
to queries with RD=1 and DO=0.)

However this still doesn't meet your requirement for "a single set of data", 
unless you are only talking about zone data, and in that case you could 
replicate all the RPZ zone files to all authoritative nameservers, and then 
configure each server to specify only one of these in its "response-policy" 
configuration?

But the anycast suggestion sounds like it has the most merit? Or at least it 
sounds the coolest to me. :-)

Nick.

P.S. I don't think this will be useful to you, but FWIW... if your goal is 
simply to have the recursive resolvers use a specific subset of nameservers for 
specific zones, then there is yet another option: static-stub zones. 
Static-stub zones allow you to effectively override the authoritative 
nameserver that will be used for a particular zone. So you could configure the 
static-stub zone on the recursive resolver, and that would point to the local 
authoritative nameserver(s). However the main drawback with static-stub zones 
is that you need to create a static-stub zone (on the local resolver) for every 
authoritative zone that you are doing this with, so it probably isn't practical 
if you have many zones or are adding or removing zones frequently?
-- 
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: per record responses based on originating IP

[Nick Tait via bind-users]

On 16/05/22 20:05, Angus Clarke wrote:
As mentioned in a separate reply to Grant, the goal is to have 
(amongst other things) local recursors "find" the locally deployed 
authoritative servers through NS records. What hasn't been mentioned 
is that I am also looking to simplify configuration management by 
means of a single set of data which can be deployed to all 
authoritative servers - I don't think the RPZ solution proposed by 
Nick achieves that.


That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.


Hi Angus.

Thanks for clarifying. Based on what you've said, what I proposed 
probably has slightly more merit than I concluded, although admittedly 
it doesn't quite tick all the boxes...


Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are 
represented as prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I 
was specifying a single host which is why the RPZ-CLIENT-IP records all 
started with 32.


Secondly, RPZs are more commonly used on recursive resolvers rather than 
the authoritative nameservers for the zone, although in your case if you 
are wanting to change the answer that an authoritative nameserver gives 
to the NS question from the recursive resolver, then it probably makes 
the most sense to put the RPZ on the authoritative nameserver. In this 
case you'd also need to specify "recursive-only no". (FYI Default 
behaviour is to apply RPZ rewriting to queries with RD=1 and DO=0.)


However this still doesn't meet your requirement for "a single set of 
data", unless you are only talking about zone data, and in that case you 
could replicate all the RPZ zone files to all authoritative nameservers, 
and then configure each server to specify only one of these in its 
"response-policy" configuration?


But the anycast suggestion sounds like it has the most merit? Or at 
least it sounds the coolest to me. :-)


Nick.

P.S. I don't think this will be useful to you, but FWIW... if your goal 
is simply to have the recursive resolvers use a specific subset of 
nameservers for specific zones, then there is yet another option: 
static-stub zones. Static-stub zones allow you to effectively override 
the authoritative nameserver that will be used for a particular zone. So 
you could configure the static-stub zone on the recursive resolver, and 
that would point to the local authoritative nameserver(s). However the 
main drawback with static-stub zones is that you need to create a 
static-stub zone (on the local resolver) for every authoritative zone 
that you are doing this with, so it probably isn't practical if you have 
many zones or are adding or removing zones frequently?
-- 
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: per record responses based on originating IP

[Angus Clarke]

Thanks for taking the time Nick and Grant,

As mentioned in a separate reply to Grant, the goal is to have (amongst other 
things) local recursors "find" the locally deployed authoritative servers 
through NS records. What hasn't been mentioned is that I am also looking to 
simplify configuration management by means of a single set of data which can be 
deployed to all authoritative servers - I don't think the RPZ solution proposed 
by Nick achieves that.

That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.

So aside from the anycast suggestion, is there anything else I can look at with 
bind itself?
 - I didn't find much with respect to limiting a sortlist response to the first 
X responses.
 - Admittedly I don't very well understand the RPZ documentation but I get the 
feeling it is not the way to go.
 - Views seem to require duplications of the whole zonefile (this might be the 
only way to go) - I did find mention of "attach-cache" but this seems to be 
more about performance than anything else. I could create views for all of my 
networks - this is automatable.

Thanks
Angus




From: bind-users  on behalf of Nick Tait via 
bind-users 
Sent: 14 May 2022 02:34
To: bind-users@lists.isc.org 
Subject: Re: per record responses based on originating IP

On 13/05/22 09:02, Grant Taylor via bind-users wrote:
On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:
This sounds like exactly the sort of use case for Response Policy Zones:

How are you going to have RPZ return different addresses for different clients? 
 Are you suggesting use different RPZs with different contents for different 
clients?

Yes, although now that I think through the details it turns out to be much 
messier than I first thought, because there doesn't seem to be a way to specify 
"not" in the RPZ...

Also I should point out that I'm assuming that a PASSTHRU result in one RPZ 
will still result in subsequent RPZs being processed. I haven't actually tested 
this, so its possible I'm misunderstanding the documentation?

Anyway in the interests of following this all the way though, let's assume you 
had 3 clients and you wanted them to each receive a different answer to the 
query 
"www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>":

Suppose their IP addresses are:

A = 192.0.2.10
B = 192.0.2.20
C = 192.0.2.30

Then, if I'm not mistaken, you could create 3 RPZ zones:

Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

; Don't overwrite the answer for queries received from clients B & C
32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

; Change the answer to the question 
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
 IN A 10.0.0.1

Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

; Don't overwrite the answer for queries received from clients A & C
32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

; Change the answer to the question 
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
 IN A 10.0.0.2

Zone file for "c.rpz.mylocaldomain.com" contains (in addition to 

Re: per record responses based on originating IP

[Grant Taylor via bind-users]

On 5/15/22 7:28 AM, Angus Clarke wrote:

Hi Grant


Hi Angus,


maybe, I'm reading up ...

poking around the manual, are you alluding to the "sortlist" directive?


Yes, that's what I was referring to.

So the concern with returning an ordered RRset is that the set could be 
large:


Okay.

I assume that's opposed to returning small distinct / unique RR sets 
with per client granularity.


The intention is that each private site/network will have its own DNS 
server pair and that local recursors resolve all private zones from that 
local pair. So things like NS records would be in scope for the ordered 
RRset response. With more sites come more DNS pairs and therefore more 
NS records to be added to the RRset. Maybe I can limit a RRset response 
to the first X number of entries?


Hum.

With this description in mind, I'd be tempted to do something with the 
anycast methodology that was recently discussed.  Return one small RRset 
that references the fixed set of any cast NS IPs.  Then routing at each 
site will get clients to the local instance of those anycasted IPs.


This would probably scale a lot better.


Thanks


:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: per record responses based on originating IP

[Angus Clarke]

Hi Grant

> Before stepping up to views I'd stop to ask the question, would
> returning multiple IPs in a preferred sort order suffice?

maybe, I'm reading up ...

> BIND has the ability to sort RRs differently based on different client
> criteria.

poking around the manual, are you alluding to the "sortlist" directive?

> If sorting of replies won't suffice, please provide a hypothetical
> example of a couple of different clients & responses for an example RR.

So the concern with returning an ordered RRset is that the set could be large:
The intention is that each private site/network will have its own DNS server 
pair and that local recursors resolve all private zones from that local pair. 
So things like NS records would be in scope for the ordered RRset response. 
With more sites come more DNS pairs and therefore more NS records to be added 
to the RRset. Maybe I can limit a RRset response to the first X number of 
entries?

Thanks
Angus


From: bind-users  on behalf of Grant Taylor 
via bind-users 
Sent: 12 May 2022 18:11
To: bind-users@lists.isc.org 
Subject: Re: per record responses based on originating IP

On 5/12/22 6:30 AM, Angus Clarke wrote:
> Hello

Hi,

> With bind (and others) it seems that DNS views are the way to go,

Before stepping up to views I'd stop to ask the question, would
returning multiple IPs in a preferred sort order suffice?

BIND has the ability to sort RRs differently based on different client
criteria.

> Does bind have some simple way to respond differently based on source
> address but on a per record basis? Or perhaps include a baseline zone in
> a view and separately include differences for that view - something like
> this perhaps?

If sorting of replies won't suffice, please provide a hypothetical
example of a couple of different clients & responses for an example RR.



--
Grant. . . .
unix || die

-- 
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: per record responses based on originating IP

[Nick Tait via bind-users]

On 13/05/22 09:02, Grant Taylor via bind-users wrote:

On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:

This sounds like exactly the sort of use case for Response Policy Zones:


How are you going to have RPZ return different addresses for different 
clients?  Are you suggesting use different RPZs with different 
contents for different clients?


Yes, although now that I think through the details it turns out to be 
much messier than I first thought, because there doesn't seem to be a 
way to specify "not" in the RPZ...


Also I should point out that I'm assuming that a PASSTHRU result in one 
RPZ will still result in subsequent RPZs being processed. I haven't 
actually tested this, so its possible I'm misunderstanding the 
documentation?


Anyway in the interests of following this all the way though, let's 
assume you had 3 clients and you wanted them to each receive a different 
answer to the query "www.example.com":


Suppose their IP addresses are:

   A = 192.0.2.10
   B = 192.0.2.20
   C = 192.0.2.30

Then, if I'm not mistaken, you could create 3 RPZ zones:

Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients B & C
   32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.1

Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients A & C
   32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.2

Zone file for "c.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients A & B
   32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.3

And then configure BIND to use all three RPZs:

   response-policy {
    zone "a.rpz.mylocaldomain.com";
    zone "b.rpz.mylocaldomain.com";
    zone "c.rpz.mylocaldomain.com";
   };

Scalability is obviously a challenge with this particular solution! :-(

So on reflection, there are probably better solutions to the problem 
that you are trying to solve. Although I don't personally have 
experience with it, wonder if "dnsmasq" might do what you need?


Thanks,

Nick.
-- 
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: per record responses based on originating IP

[Grant Taylor via bind-users]

On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:

This sounds like exactly the sort of use case for Response Policy Zones:


How are you going to have RPZ return different addresses for different 
clients?  Are you suggesting use different RPZs with different contents 
for different clients?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: per record responses based on originating IP

[Nick Tait via bind-users]

On 13/05/2022 12:30 am, Angus Clarke wrote:
Does bind have some simple way to respond differently based on source 
address but on a per record basis? Or perhaps include a baseline zone 
in a view and separately include differences for that view - something 
like this perhaps?


Hi Angus.

This sounds like exactly the sort of use case for Response Policy Zones: 
https://bind9.readthedocs.io/en/v9_18_2/reference.html#response-policy-zone-rpz-rewriting


Nick.

--
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: per record responses based on originating IP

[Grant Taylor via bind-users]

On 5/12/22 6:30 AM, Angus Clarke wrote:

Hello


Hi,


With bind (and others) it seems that DNS views are the way to go,


Before stepping up to views I'd stop to ask the question, would 
returning multiple IPs in a preferred sort order suffice?


BIND has the ability to sort RRs differently based on different client 
criteria.


Does bind have some simple way to respond differently based on source 
address but on a per record basis? Or perhaps include a baseline zone in 
a view and separately include differences for that view - something like 
this perhaps?


If sorting of replies won't suffice, please provide a hypothetical 
example of a couple of different clients & responses for an example RR.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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

per record responses based on originating IP

[Angus Clarke]

Hello

I'm familiar with Dan Bernstein's aging DNS software. With it I can add 
location based responses to individual records, so that the DNS can respond 
differently to a name lookup according to the source network/IP on a per-record 
basis.

With bind (and others) it seems that DNS views are the way to go, however as 
far as I understand I have to recreate an entire zone for each view, which 
seems a bit overkill for a zone of hundreds of records to only have a handful 
of records responded to differently.

Does bind have some simple way to respond differently based on source address 
but on a per record basis? Or perhaps include a baseline zone in a view and 
separately include differences for that view - something like this perhaps?

Thanks
Angus
-- 
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

AW: all resource record types and examples

[Klaus Darilion via bind-users]

As I have such a zone I will paste it here. But fore sure it is not complete as 
it was created some time ago.
regards
Klaus


$ cat types.test
$TTL 60 ; 1 minute
@   IN SOA  sec1.rcode0.net. rcodezero.ipcom.at. (
36   ; serial
1200   ; refresh (20 minutes)
3600   ; retry (1 hour)
604800 ; expire (1 week)
60; minimum (1 minutes)
)

@   NS  ns3.example.com.

A   IN  A   127.0.0.1
IN  2000::1
AFSDB   IN  AFSDB   1 afs.example.com.
ALIAS   IN  TYPE65401 \# 12 0377036E696302617400
CAA IN  CAA 128 issue "letsencrypt.org"
CDNSKEY IN  CDNSKEY 256 3 8 
AwEAAff+pyxoKgbxjywWKXe+sUkoygZpVvZubhpNCHVf727CwezWaXOMGg62Lz+ijAi2u7MNRN+LJtaleewNMAGJ+fx6GTn3pSgZjyI+J+YdWD+8dORyuag1rQ+04i/LjJpEtO/PNOoD7Pz1FQlLxzx36Vd/nSQSZbEZiLXCf3LDsjKTwWhRLnt85VOKcFylplFAhUoLRkQpOD/A3eZR7lL6Z5RijN+ii+DtPorzFbFmd0de/VPTwEK6l1f8FsfONBzzTQ==
CDS IN  CDS 49189 5 1 97d6d9dd5afa5ebe258e2c3631fed338ca613f9d
CERTIN  CERT6 0 0 
FGOzZ3SxhaY/J5YoupAK6P7+u74waHR0cDovL3BrYS5rbGVlbi5jaC9nbnVwZy5hc2M=
CNAME   IN  CNAME   cname.example.com.
DNAME   IN  DNAME   dname.example.com.
DNSKEY  IN  DNSKEY  256 3 8 
AwEAAff+pyxoKgbxjywWKXe+sUkoygZpVvZubhpNCHVf727CwezWaXOMGg62Lz+ijAi2u7MNRN+LJtaleewNMAGJ+fx6GTn3pSgZjyI+J+YdWD+8dORyuag1rQ+04i/LjJpEtO/PNOoD7Pz1FQlLxzx36Vd/nSQSZbEZiLXCf3LDsjKTwWhRLnt85VOKcFylplFAhUoLRkQpOD/A3eZR7lL6Z5RijN+ii+DtPorzFbFmd0de/VPTwEK6l1f8FsfONBzzTQ==
DS  IN  DS  49189 5 1 97d6d9dd5afa5ebe258e2c3631fed338ca613f9d
HINFO   IN  HINFO   PC-Intel-700mhz "Redhat Linux 7.1"
LOC IN  LOC 48 11 6.400 N 16 20 0.200 E 190.00m 1.00m 100.00m 10.00m
MB  IN  MB  mb.example.com.
MX  IN  MX  10 mail.example.com.
NAPTR   IN  NAPTR   0 0 "S" "SIP+D2U" "" _sip._udp.videogw.example.net.
NAPTR   IN  NAPTR   1 0 "S" "SIP+D2U" "" _sip._tcp.videogw.example.net.
NS  IN  NS  ns1.example.com.
NS  IN  NS  ns2.example.com.
OPENPGPKEY IN   OPENPGPKEY 
mQGiBEyXadoRBADTUoaVczNG3ras9/nqhHVduWDjxi0wbhMfRpciB2NK9T5YVVPqLPDtRCpso07a
PTR IN  PTR ptr.example.com.
RP  IN  RP  serveradmin.example.at. serveradmin.example.at.
SMIMEA  IN  SMIMEA  0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 
7983a1d16e8a410e4561cb106618e971
; SPF hatte mal einen eigenen Typ, aber laut RFC soll nur TXT verwendet werden
SPF IN  SPF "v=spf1 mx -all"
SPF IN  TXT "v=spf1 mx -all"
SRV IN  SRV 0 0 5060 vgw1.a1.net.
SSHFP   IN  SSHFP   4 1 8915504c4136d16f6c9c81d15e295b66089fa4e2
TLSAIN  TLSA3 1 1 
0eb9e66d24d72f85db53a982af5befa1e6043565b5792ba8cde2ae17c9b8d92e
TXT IN  TXT ganzkurz
TXT IN  TXT "das ist ein kurzer Text"
TXT IN  TXT "dieser TXT record ist genau 255 zeichen lang 567890 
1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 
1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 
1234567890 1234567890 1234567890 1234567890 12345"
;TXTIN  TXT "das ist ein langer, sehr sehr sehr langer Text 50" 
"das ist ein langer, sehr sehr sehr langer Text 50" "das ist ein langer, sehr 
sehr sehr langer Text 50" "das ist ein langer, sehr sehr sehr langer Text 50" 
"das ist ein langer, sehr sehr sehr langer Text 50" "das ist ein langer, sehr 
sehr sehr langer Text300"
URIIN  URI 10 1 "ftp://ftp1.example.com/public;
WKS IN  WKS 1.1.1.1 TCP ( smtp discard rpc )



Von: bind-users  Im Auftrag von rams
Gesendet: Dienstag, 12. April 2022 14:43
An: bind-users 
Betreff: all resource record types and examples

Hi,
Greetings ...
Could someone please share all supported DNS RRs and examples of each RR.

Regards,
Ramesh

-- 
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: all resource record types and examples

[Anand Buddhdev]

Hi Ramesh,

This is the kind of information that you can easily find by Googling, so 
please go and do the research yourself.


Folk on this mailing list help others by volunteering their time for 
free, and get no compensation for it. We would be happy to help with 
specific questions about BIND, but I don't think anyone would be happy 
to do your work for you.


Regards,
Anand

On 12/04/2022 14:43, rams wrote:

Hi,
Greetings ...
Could someone please share all supported DNS RRs and examples of each RR.

Regards,
Ramesh



--
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: all resource record types and examples

[Ray Bellis]

On 12/04/2022 13:43, rams wrote:


Could someone please share all supported DNS RRs and examples of each RR.


That's a *very* big ask.

IANA maintains a list of all RRs and pointers to the documentation for 
each of them:




Ray

--
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

all resource record types and examples

[rams]

Hi,
Greetings ...
Could someone please share all supported DNS RRs and examples of each RR.

Regards,
Ramesh
-- 
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: Can an RPZ record be used for a non-existed domain?

[Philippe.Simonet]

you maybe have to use

>>> qname-wait-recurse no

to avoid DNS failures to be propgated.

philippe

From: bind-users  On Behalf Of VASILAKIS 
GEORGIOS
Sent: Thursday, 24 March 2022 09:53
To: bind-users@lists.isc.org
Subject: Can an RPZ record be used for a non-existed domain?

Hello,

I have an RPZ containing 2700 Records using A record redirection.

Is it possible to add records for non-existing domains to the RPZ?

BR,
Giorgos

CONFIDENTIALITY NOTE: This e-mail is originated from WIND Hellas 
Telecommunications S.A.. Both this message and any attachments hereto are 
confidential, may contain legally privileged information and are intended 
solely for the use of the individual (or entity) to whom it is addressed. The 
contents hereof should not be disclosed to anyone other than the addressee(s). 
Unauthorised recipients hereof are requested to maintain this confidentiality 
and to advise us at our expense of any errors in transmission and to 
immediately destroy the received message together with any attachments and any 
copies thereof. Any unauthorised dissemination or copying of this e-mail or its 
attachments, and any use or disclosure of any information contained therein is 
strictly prohibited.
-- 
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: Can an RPZ record be used for a non-existed domain?

[Grant Taylor via bind-users]

On 3/24/22 4:34 PM, Carl Byington via bind-users wrote:

Yes, the disconnect was my brain. I will try to plug that back in.


;-)

We've all had those days.  Most of us will have them again.


How do you do that in /etc/hosts?


It's been a while, so I'm relying on memory, a.k.a. lossy media.

   /etc/hosts:
  a.b.c.d   outbound.example.com

Really that simple.  Forward lookup would search names (right hand 
side).  Reverse lookup would search the IPs (left hand side).


Maybe this is somewhat dependent on the stub resolver library on the 
system and / or the system itself.  It's been 5-15 years since I've last 
done this.  It could be very likely that things were quite different 25 
years ago.



For some users, for some (possibly all) senders, we require that d.c.b.a
.in-addr.arpa has some PTR record where the corresponding A record
resolves back to a.b.c.d.


There is also a key difference in what you've said vs what I've said. 
You seem to be using DNS specific terminology while I'm using host 
generic name resolution.  The former doesn't support /etc/hosts while 
the latter does.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Can an RPZ record be used for a non-existed domain?

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2022-03-24 at 16:13 -0600, Grant Taylor via bind-users wrote:

> But there seems to be a disconnect.

> I was talking about adding a domain that is outbound.example.com. and
> put the A /  records in that domain's apex.  Thus you are only
> overriding outbound.example.com and nothing else in the example.com
> domain.

Yes, the disconnect was my brain. I will try to plug that back in.


> We must have different experiences and / or have used different MTAs.
> I've routinely been able to address one offs do to lack of PTR via
> /etc/hosts entries.

How do you do that in /etc/hosts? Suppose the mail arrives from a.b.c.d,
and they have some name outbound.example.com A a.b.c.d, but d.c.b.a.in-
addr.arpa does not exist.

For some users, for some (possibly all) senders, we require that d.c.b.a
.in-addr.arpa has some PTR record where the corresponding A record
resolves back to a.b.c.d.


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYjzxpxUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsHPYgCeNHTOSOzTq78dKjx6/WUyfJ2w8+kA
nAqRrCYz72YZrMxyH7OYcP6VCM3R
=l8G6
-END PGP SIGNATURE-


-- 
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: Can an RPZ record be used for a non-existed domain?

[Grant Taylor via bind-users]

On 3/24/22 3:50 PM, Carl Byington via bind-users wrote:
In general, the domain exists with a bunch of existing names - www, 
mail, etc. We just need to add one more (outbound) and tie it to the 
ip address of their outbound mail server. I don't want to take over 
their entire domain. 


Fair enough.

But there seems to be a disconnect.

I was talking about adding a domain that is outbound.example.com. and 
put the A /  records in that domain's apex.  Thus you are only 
overriding outbound.example.com and nothing else in the example.com domain.


Rather than updating /etc/hosts on a bunch of customer mail servers, 
their dns server just zone transfers the rpz zone using notify/ixfr.


ACK  Using standard zone transfers for RPZ(s) is one of the many 
features of RPZ.


And many times, their error is in an incorrect or missing PTR record, 
so /etc/hosts does not help there.


We must have different experiences and / or have used different MTAs. 
I've routinely been able to address one offs do to lack of PTR via 
/etc/hosts entries.


But this is one rpz file to maintain, rather than adding a few hundred 
zones to the dns servers.


Fair enough.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Can an RPZ record be used for a non-existed domain?

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2022-03-24 at 12:16 -0600, Grant Taylor via bind-users wrote:
> What advantage does RPZ have in this case over just hosting the
> domain(s) locally?

In general, the domain exists with a bunch of existing names - www,
mail, etc. We just need to add one more (outbound) and tie it to the ip
address of their outbound mail server. I don't want to take over their
entire domain. Rather than updating /etc/hosts on a bunch of customer
mail servers, their dns server just zone transfers the rpz zone using
notify/ixfr. And many times, their error is in an incorrect or missing
PTR record, so /etc/hosts does not help there.

I have many other cases where we do take over the entire domain, like

princetonprivacystudy.orgA   127.0.0.2
*.princetonprivacystudy.org  A   127.0.0.2

which makes any host name like abc.princetonprivacystudy.org appear to
be listed on Zen.

But this is one rpz file to maintain, rather than adding a few hundred
zones to the dns servers.

-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYjznjBUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsE8PwCeJRLLeGhQE9E51mreW3Yuq2g0Ig0A
n29Nl0oy3X0503WD3h9Udg1rEBoW
=DwNb
-END PGP SIGNATURE-


-- 
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: Can an RPZ record be used for a non-existed domain?

[Grant Taylor via bind-users]

On 3/24/22 10:02 AM, Carl Byington via bind-users wrote:

I think so.


Agreed.

Presumably to create those domains locally. Of course the rest of 
the world won't see them.


1.0.0.127.in-addr.arpaPTR outbound.example.com.
outbound.example.com  A   127.0.0.1


What advantage does RPZ have in this case over just hosting the 
domain(s) locally?


Aside:  I've usually gotten around this specific problem via entries in 
/etc/hosts.  Maybe the software is more picky than what I've run into 
before.


I am a fan of RPZ and use it often.  I'm still trying to find which tool 
to use in various situations.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Can an RPZ record be used for a non-existed domain?

[Fred Morris]

On Thu, 24 Mar 2022, VASILAKIS GEORGIOS wrote:

I have an RPZ containing 2700 Records using A record redirection.


I've got an RPZ with thousands of PTR records! I don't know how many 
domains that means I took over, although some of them clearly don't exist 
because I get NXDOMAIN when trying to look up the legitimate records.



Is it possible to add records for non-existing domains to the RPZ?


I have another RPZ which I use for labeled uses. This results in local 
search lists being consulted, so I see things like 
foo.example.com.example.com, foo.example.com.com (and if they exist they 
shouldn't) and I block them (e.g. *.com.com) to prevent information 
leakage and garbage traffic.


HTH...

--

Fred Morris, internet plumber

--
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: Can an RPZ record be used for a non-existed domain?

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2022-03-24 at 16:48 +0100, Benny Pedersen wrote:
> > Is it possible to add records for non-existing domains to the RPZ?

I think so.

> what is the point ?

Presumably to create those domains locally. Of course the rest of the
world won't see them.

For example, I have some clients using a sendmail milter, which for some
users requires matching forward/reverse dns. And there are some senders
that just cannot seem to get that right. So we add

1.0.0.127.in-addr.arpaPTR outbound.example.com.
outbound.example.com  A   127.0.0.1

to force matching forward/reverse dns. But that creates the name
outbound.example.com locally, where that name does not exist in the
global name space.


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYjyVrRUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsEu8ACfWgB0gXmrfZrsLrZ2+3b/K+PYgDkA
n18rhjSH1nRnxXepbbttXLr03FZS
=mTOI
-END PGP SIGNATURE-


-- 
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: Can an RPZ record be used for a non-existed domain?

[Benny Pedersen]

On 2022-03-24 09:52, VASILAKIS GEORGIOS wrote:


I have an RPZ containing 2700 Records using A record redirection.


congrats :)


Is it possible to add records for non-existing domains to the RPZ?


what is the point ?

dont waste resources
--
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 an RPZ record be used for a non-existed domain?

[VASILAKIS GEORGIOS]

Hello,

I have an RPZ containing 2700 Records using A record redirection.

Is it possible to add records for non-existing domains to the RPZ?

BR,
Giorgos


CONFIDENTIALITY NOTE: This e-mail is originated from WIND Hellas 
Telecommunications S.A.. Both this message and any attachments hereto are 
confidential, may contain legally privileged information and are intended 
solely for the use of the individual (or entity) to whom it is addressed. The 
contents hereof should not be disclosed to anyone other than the addressee(s). 
Unauthorised recipients hereof are requested to maintain this confidentiality 
and to advise us at our expense of any errors in transmission and to 
immediately destroy the received message together with any attachments and any 
copies thereof. Any unauthorised dissemination or copying of this e-mail or its 
attachments, and any use or disclosure of any information contained therein is 
strictly prohibited.
-- 
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: RPZ rule to apply to NS record requests?

[John Thurston]

On 11/16/2021 2:41 AM, Tony Finch wrote:

John Thurston  wrote:


If I have a Reverse Policy Zone (RPZ) defined, I can define a specific answer
to be sent for a specific record-type for a specific name:

foo.bar.com  IN  A  10.11.12.13
foo.bar.com  IN TXT "Hello World"

But I can't seen to define one for the record-type NS

Is this possible?


The RPZ documentation doesn't say you can't include NS records as "local
data", but I guess you might trip over BIND's checks for what makes sense
at a zone cut: in a normal zone you can't have A and TXT and NS at the
same name (unless it's the zone apex).

But even if it did work, it's unlikely to do what you want. (You didn't
say why you want NS records so that's a somewhat risky assumption...)


TLDR; I'm trying to cover up someone else's mess


I didn't describe the reason because it is painful.

We use products from Major Software (hereafter referred to as MS). They 
use DNS to provide pointers to public and private versions of similar 
services. These pointers are served from public or private authoritative 
servers owned and operated by MS. The zones defined on the public 
authorities contain both SOA and NS records for each zone. The zones 
defined on the private authorities have only the SOA records.


Per RFC, an SOA and NS are the minimal records required of a zone. When 
we define forward-zones in our internal resolvers (e.g. Please send 
queries for these private names directly to this MS resolver), our 
automated monitoring system goes berserk. "Danger! Danger! The zone 
privatelink.MS.net is invalid! It has no NS record!! Danger! Something 
is wrong! Stop forwarding! Call the Authorities!"


I recognize MS probably doesn't care they are serving up an invalid 
zone. I also recognize that my bosses probably are not going to quit 
using products and services from MS. I don't want to try to dismantle 
(or cripple) the monitoring system which is keeping an eye on all the 
other zones for which we forward. I'm, therefore, left trying to imagine 
someway to abuse something in my control so my monitoring system doesn't 
notice these private MS zones are invalid.


I had _hoped_ I could use an RPZ to say:
  privatelink.MS.net  IN  NS  127.0.0.1

My monitoring system would query DNS, find the SOA (from the real 
authorities) and an NS (from my RPZ) and go away happy.


I recognize that the correct answer is to convince MS to correctly 
publish their private zones. But after a couple of decades of working 
with products from Major Software, I have more confidence I'll score on 
the next Powerball than they will acknowledge the deficiency (let alone 
consider correcting it).







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

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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: RPZ rule to apply to NS record requests?

[Tony Finch]

John Thurston  wrote:

> If I have a Reverse Policy Zone (RPZ) defined, I can define a specific answer
> to be sent for a specific record-type for a specific name:
>
>foo.bar.com  IN  A  10.11.12.13
>foo.bar.com  IN TXT "Hello World"
>
> But I can't seen to define one for the record-type NS
>
> Is this possible?

The RPZ documentation doesn't say you can't include NS records as "local
data", but I guess you might trip over BIND's checks for what makes sense
at a zone cut: in a normal zone you can't have A and TXT and NS at the
same name (unless it's the zone apex).

But even if it did work, it's unlikely to do what you want. (You didn't
say why you want NS records so that's a somewhat risky assumption...)
In typical setups, RPZ is deployed on recursive servers, whose clients are
basically all stub resolvers. Stubs don't do anything special with NS
records, and they almost never make NS queries. So normally, using RPZ to
substitue NS records will not have any useful effect.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and
North Channel: Southwesterly veering westerly, 5 or 6. Slight or
moderate, occasionally rough near Mull of Kintyre. Rain then showers.
Good, occasionally moderate at first.

___
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

RPZ rule to apply to NS record requests?

[John Thurston]

If I have a Reverse Policy Zone (RPZ) defined, I can define a specific 
answer to be sent for a specific record-type for a specific name:


   foo.bar.com  IN  A  10.11.12.13
   foo.bar.com  IN TXT "Hello World"

But I can't seen to define one for the record-type NS

Is this possible?


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

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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: A record for @?

[Tony Finch]

@lbutlr via bind-users  wrote:

> I have a domain that I hot DNS and email for, but not web. I set the A
> record for www.example.com to the IP of the web server with nsupdate,
> removing the old CNAME the pointed to the local webserver, but the web
> monkey for the new website is saying that www has to be a CNAME and the
> @ record should be the A record pointing to the IP.

You can do that, but it might have weird effects if someone tries to send
email to someth...@www.example.com. I generally think it's neater for both
the zone file origin (aka @) and the www subdomain to have A/ records
pointing at the web server.

> I don't think this is right, and if it is I am not sure how to use
> nsupdate to make this change.

@ is just an abbreviation for (in this case) example.com (it's handy for
writing instructions or zone file that work the same for any domain name).

In cases where there isn't an implicit origin, such as nsupdate, you need
to write the records out in full instead, e.g.

www.example.com. CNAME example.com.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Foreland to Selsey Bill: Northwesterly, backing westerly or
southwesterly 3 or 4, increasing 4 to 6 later. Smooth or slight,
occasionally moderate later. Showers later. Good.

___
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

A record for @?

[@lbutlr via bind-users]

I have a domain that I hot DNS and email for, but not web. I set the A record 
for www.example.com to the IP of the web server with nsupdate, removing the old 
CNAME the pointed to the local webserver, but the web monkey for the new 
website is saying that www has to be a CNAME and the @ record should be the A 
record pointing to the IP.

I don't think this is right, and if it is I am not sure how to use nsupdate to 
make this change.


-- 
'Yes, but humans are more important than animals,' said Brutha. 'This
is a point of view often expressed by humans,' said Om. (Small
Gods)

___
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

[Matus UHLAR - fantomas]

On 25.06.21 18:29, Bruce  Johnson wrote:

Thank you…this is very useful information; I thought TTL could only be 
specified on a per-zone basis, not per-host.


not even per-host. Different RR types for the same host can have different
TTL.


mail1m  IN  A   xxx.xxx.xxx.52; dhbex1
mail1m  IN  A   xxx.xxx.xxx.54; dhbex2


mail1d  IN  TXT "v=spf1 a -all"
mail1h  IN  MX  0   mail

etc.
Only same RR types MUST have same value so e.g.:

mail1m  IN  A   xxx.xxx.xxx.52; dhbex1
mail2m  IN  A   xxx.xxx.xxx.54; dhbex2

would be incorrect and server will choose one of those to implement for all
RRs (see rfc 2182 section 5.2)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux IS user friendly, it's just selective who its friends are...
___
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

[Bruce Johnson]

Thank you…this is very useful information; I thought TTL could only be 
specified on a per-zone basis, not per-host.

On Jun 25, 2021, at 11:10 AM, Richard T.A. Neal 
mailto:rich...@richardneal.com>> wrote:

Hi Bruce,

Here you're specifying a distinct TTL for those records which overrides the 
default TTL for this zone (which you will have set towards the top of the file 
with the rest of the defaults)

1m = 60 seconds:
https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/s1-bind-zone.html

So you're essentially telling DNS clients that the value provided for 
mail.{your-fqdn} is only valid for 60 seconds. As you say, a cheap load 
balancing attempt!

Best,

Richard.

-Original Message-
From: bind-users  On Behalf Of Bruce Johnson
Sent: 25 June 2021 6:56 pm
To: bind-users@lists.isc.org
Subject: Odd A record in our hosts zone file

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

--
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

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

[Richard T.A. Neal]

Hi Bruce,

Here you're specifying a distinct TTL for those records which overrides the 
default TTL for this zone (which you will have set towards the top of the file 
with the rest of the defaults)

1m = 60 seconds:
https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/s1-bind-zone.html

So you're essentially telling DNS clients that the value provided for 
mail.{your-fqdn} is only valid for 60 seconds. As you say, a cheap load 
balancing attempt!

Best,

Richard.

-Original Message-
From: bind-users  On Behalf Of Bruce Johnson
Sent: 25 June 2021 6:56 pm
To: bind-users@lists.isc.org
Subject: Odd A record in our hosts zone file

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

Odd A record in our hosts zone file

[Bruce Johnson]

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

Re: Reverse Lookup / PTR record

[techlists]

On 2021-06-21 12:00, Matus UHLAR - fantomas wrote:

On 21.06.21 09:41, techli...@phpcoderusa.com wrote:
I am configuring a home office PHP webserver on my cable company's 
business connection that allows for servers.


My cable company provides the reverse lookup / PTR record.  Given 
that, I'm thinking I need to provide only the zone file, no reverse 
lookup.


if your ISP provides reverse lookup, you don't need reverse zone file 
at

all.


Any thoughts are much appreciated.


what is your question?


You answered it  it was do I need a reverse if my ISP is providing 
one.  Thanks!!





--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a 
Macintosh".

___
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: Reverse Lookup / PTR record

[Matus UHLAR - fantomas]

On 21.06.21 09:41, techli...@phpcoderusa.com wrote:
I am configuring a home office PHP webserver on my cable company's 
business connection that allows for servers.


My cable company provides the reverse lookup / PTR record.  Given 
that, I'm thinking I need to provide only the zone file, no reverse 
lookup.


if your ISP provides reverse lookup, you don't need reverse zone file at
all.


Any thoughts are much appreciated.


what is your question?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".
___
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

Reverse Lookup / PTR record

[techlists]

Hi,

I am configuring a home office PHP webserver on my cable company's 
business connection that allows for servers.


My cable company provides the reverse lookup / PTR record.  Given that, 
I'm thinking I need to provide only the zone file, no reverse lookup.


Any thoughts are much appreciated.

___
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: Bind9.16 zone SOA record issue.

[Grant Taylor via bind-users]

On 5/23/21 9:27 AM, Ondřej Surý wrote:
Nope, that’s how you enter email to SOA with dot in user part as 
the first dot gets converted to @.


#TodayIlearned

I agree with Ondřej.  I think it's the missing $ in front of ORIGIN. 

Remember the $ lines are directives to BIND and not zone data. 
ORIGIN without the leading $ would be zone data.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Bind9.16 zone SOA record issue.

[Ondřej Surý]

Nope, that’s how you enter email to SOA with dot in user part as the first dot 
gets converted to @.

--
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 23. 5. 2021, at 17:15, Sten Carlsen  wrote:
> 
> The "\" above is what I would suspect. I could be wrong.

___
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: Bind9.16 zone SOA record issue.

[Sten Carlsen]

> On 23 May 2021, at 16.24, Thomas Strike  wrote:
> 
> ZONE FILE:
> $ttl 3600
> ORIGIN ancienttom.us .
> @IN SOA ancienttom.us . 
> thomas\.strike.sleepyvalley.net . (

The "\" above is what I would suspect. I could be wrong.

> 1588097734
> 1200
> 600
> 86400
> 3600 )

___
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: Bind9.16 zone SOA record issue.

[Ondřej Surý]

$ORIGIN ancienttom.us.

?

--
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 23. 5. 2021, at 16:24, Thomas Strike  wrote:
> 
> ORIGIN ancienttom.us.

___
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

Bind9.16 zone SOA record issue.

[Thomas Strike]

I've been pounding my head over this issue all day with no results.

I am hosting Bind9.16 on a Ubuntu 20.04 server.

I have several zone records that report the same problem but I also have 
several zoned that are configured with this same template and run okay 
on the server. I've surfed the Internet for any clues and tried 
everything I can think of but cannot get rid of this problem.

I really would appreciate any help I can get.

ZONE FILE:
$ttl 3600
ORIGIN ancienttom.us.
@    IN SOA ancienttom.us. thomas\.strike.sleepyvalley.net. (
    1588097734
    1200
    600
    86400
    3600 )
ancienttom.us.   1H    IN 
NS  ns1.Sleepyvalley.net.
ancienttom.us.   1H    IN 
NS  ns2.Sleepyvalley.net.
ancienttom.us.           IN 
A   51.222.143.198
ns1.ancienttom.us.         IN 
A   51.222.143.198
ns2.ancienttom.us.     IN 
A   51.222.143.198
www.ancienttom.us.       IN 
A   51.222.143.198
ftp.ancienttom.us.          IN 
A   51.222.143.198
mailadmin.ancienttom.us.  IN A   
51.222.143.198
ancienttom.us.   1H    IN MX  10 
mx.mydomain.com.
mail.ancienttom.us.    IN 
A   66.96.163.96
smtp.ancienttom.us.   IN 
A   66.96.163.96


When I run named-checkzone I get 'unknown RR type 'ancienttom.us.'

My named.log shows;
22-May-2021 23:57:05.819 zoneload: error: zone ancienttom.us/IN: has 0 
SOA records
22-May-2021 23:57:05.819 zoneload: error: zone ancienttom.us/IN: has no 
NS records
22-May-2021 23:57:05.819 zoneload: error: zone ancienttom.us/IN: not 
loaded due to errors.



___
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: TXT & SPF Record Syntax

[Chuck Aurora]

On 2021-02-28 17:52, Mark Andrews wrote:
Domain names without a trailing period are relative to the current 
origin.


Domain names with a trailing period are absolute.


snip

On 1 Mar 2021, at 10:41, Tim Daneliuk via bind-users 
 wrote:


I am trying to understand when the LHS of a TXT record needs to be 
terminated with '.'.


For example, I see this one of the machines I am managing.  The server 
in question is

the zone authority for foo.com:

foo.com. IN TXT "v=spf1 ...
foo.com. IN SPF "v=spf1 ...
something._domainkey IN TXT "v=DKIM1 ...
_dmark.foo.com.  IN TXT "v=DMARC1 ...

Could some kind soul explain why the DKIM key name does not require 
the trailing period, but

why all the foo.com entries do?


In addition to what Mark said, you might be interested in "@".

In a zone file "@" is shorthand for the current $ORIGIN, so you could
have it like this:

;$ORIGIN example.com.
; $ORIGIN can be explicitly set anywhere in the zone file, as above, or
; if not set, it takes the value of the zone name from named.conf(5)
@  NS ns
@  SOA"..."
@  A  192.0.2.2
@  MX 0 mail
@  TXT"v=spf1 ..."
mail   A  192.0.2.25
ns A  192.0.2.53
ns A  192.0.2.35
sel._domainkey TXT"v=DKIM1 ..."

Each of the @ is read as "example.com.", and each unqualified name
has ".example.com." appended.  That applies on LHS and RHS, when a
record's RDATA includes a hostname (NS and MX in the example given.)

I should also point out that your question had nothing at all to do
with TXT nor SPF; it was simply about zone file syntax.  Trailing dot
applies to all records of all types.

And another nitpick, the SPF record type is deprecated.  It has been
reverted to the original method of using TXT.
___
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: TXT & SPF Record Syntax

[Tim Daneliuk via bind-users]

On 2/28/21 5:52 PM, Mark Andrews wrote:
> Domain names without a trailing period are relative to the current origin.
> 
> Domain names with a trailing period are absolute.
> 
> If you want to add the record
> 
>   foo.bar.example.com. TXT …
> 
> and the current origin is example.com. You can enter it as
> 
>   foo.bar TXT …
> 
> or
> 
>   foo.bar.example.com. TXT …
> 
> or you could set the origin to bar.example.com. and do this
> 
>   $ORIGIN bar.example.com.
>   foo TXT …
> 
> This applies to all domain names in zone files.
> 
> Mark

OK that makes sense.  Thanks.  It's been so long since I configured these 
servers - and
they have worked so flawlessly - I forgot everything I knew about bind config 
files ;)
___
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: TXT & SPF Record Syntax

[Mark Andrews]

Domain names without a trailing period are relative to the current origin.

Domain names with a trailing period are absolute.

If you want to add the record

foo.bar.example.com. TXT …

and the current origin is example.com. You can enter it as

foo.bar TXT …

or

foo.bar.example.com. TXT …

or you could set the origin to bar.example.com. and do this

$ORIGIN bar.example.com.
foo TXT …

This applies to all domain names in zone files.

Mark

> On 1 Mar 2021, at 10:41, Tim Daneliuk via bind-users 
>  wrote:
> 
> I am trying to understand when the LHS of a TXT record needs to be terminated 
> with '.'.
> 
> For example, I see this one of the machines I am managing.  The server in 
> question is
> the zone authority for foo.com:
> 
> foo.com. IN TXT "v=spf1 ...
> foo.com. IN SPF "v=spf1 ...
> something._domainkey IN TXT "v=DKIM1 ...
> _dmark.foo.com.  IN TXT "v=DMARC1 ...
> 
> Could some kind soul explain why the DKIM key name does not require the 
> trailing period, but
> why all the foo.com entries do?
> ___
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@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

TXT & SPF Record Syntax

[Tim Daneliuk via bind-users]

I am trying to understand when the LHS of a TXT record needs to be terminated 
with '.'.

For example, I see this one of the machines I am managing.  The server in 
question is
the zone authority for foo.com:

foo.com. IN TXT "v=spf1 ...
foo.com. IN SPF "v=spf1 ...
something._domainkey IN TXT "v=DKIM1 ...
_dmark.foo.com.  IN TXT "v=DMARC1 ...

Could some kind soul explain why the DKIM key name does not require the 
trailing period, but
why all the foo.com entries do?
___
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: SRV Record Server Availability

[Mark Andrews]

Well mDNS is not DNS.  It is a multicast request to all devices on the local 
network to respond.

To get the functionality being requested in the DNS it requires something to be 
polling the availability of the server listed in the SRV records and to 
add/remove/adjust them depending upon their load/availability.  In reality this 
should not be needed if people would just write client software to properly 
handle multi-homed servers.  There is nothing that say you must wait for a 
connection to timeout before you attempt to connect to a second address.

Happy Eyeballs RFC 8305 (previously RFC 6555) us about starting multiple 
connections across address families and only proceeding with the first that 
connects but there is NOTHING that says you can’t do the similar for all 
addresses independent of address family.

It isn’t hard to write a TCP client that attempts to connect to multiple 
servers simultaneously.

I will admit that it is slightly harder for UDP clients but in most cases it is 
not impossible.

For both protocols you do not wait seconds to get the initial response before 
trying the alternate addresses.  Most of the world is less that 300ms way 
(round trip).

Mark

> On 7 Jan 2021, at 03:42, Andrew P.  wrote:
> 
> Isn't this sort of dynamic functionality (real-time presence or absence of 
> SRV records) what mDNS and the avahi daemon are for?
> 
> 
> From: bind-users  on behalf of Matus UHLAR 
> - fantomas 
> Sent: Wednesday, January 6, 2021 8:51 AM
> To: bind-users@lists.isc.org
> Subject: Re: SRV Record Server Availability
> 
> On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote:
>> Your understanding is correct, i just thought that SRV can detect whose
>> server is alive so it can choose and provide an answer with the available
>> Server.
> 
> DNS is not designed to provide this functionality. While technically you can
> change contents of DNS depending on which servers are alive and which are
> not, it's almost never a good idea.
> 
> That means, BIND has nothing like this built in.
> 
>>> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>>>  wrote:
>>>> Is DNS Bind SRV record can detect the Server's availability? If yes, how?
> 
>> On Tue, 5 Jan 2021, 23:53 tale  wrote:
>>> Could you provide more information about your goal?  I don't fully
>>> understand the question.
>>> 
>>> For my reading, the answer is basically no, in that an SRV record just
>>> provides data about where.a particular service can be found.  It's up
>>> to other systems to fetch that data and interpret it, including
>>> whether that service is actually available at the given endpoint.  In
>>> its typical operation, BIND will just take whatever name and port the
>>> zone administrator said to provide for that SRV record, and not do any
>>> sort of availability checks on it.
>>> 
>>> However, if you go deep into a far more complicated, custom use of
>>> BIND, you could set up a process that monitors the availability and
>>> changes the SRV record accordingly.
> 
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Microsoft dick is soft to do no harm
> ___
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@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: SRV Record Server Availability

[Andrew P .]

Isn't this sort of dynamic functionality (real-time presence or absence of SRV 
records) what mDNS and the avahi daemon are for?


From: bind-users  on behalf of Matus UHLAR - 
fantomas 
Sent: Wednesday, January 6, 2021 8:51 AM
To: bind-users@lists.isc.org
Subject: Re: SRV Record Server Availability

On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote:
>Your understanding is correct, i just thought that SRV can detect whose
>server is alive so it can choose and provide an answer with the available
>Server.

DNS is not designed to provide this functionality. While technically you can
change contents of DNS depending on which servers are alive and which are
not, it's almost never a good idea.

That means, BIND has nothing like this built in.

>> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>>  wrote:
>> > Is DNS Bind SRV record can detect the Server's availability? If yes, how?

>On Tue, 5 Jan 2021, 23:53 tale  wrote:
>> Could you provide more information about your goal?  I don't fully
>> understand the question.
>>
>> For my reading, the answer is basically no, in that an SRV record just
>> provides data about where.a particular service can be found.  It's up
>> to other systems to fetch that data and interpret it, including
>> whether that service is actually available at the given endpoint.  In
>> its typical operation, BIND will just take whatever name and port the
>> zone administrator said to provide for that SRV record, and not do any
>> sort of availability checks on it.
>>
>> However, if you go deep into a far more complicated, custom use of
>> BIND, you could set up a process that monitors the availability and
>> changes the SRV record accordingly.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
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: SRV Record Server Availability

[Matus UHLAR - fantomas]

On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote:

Your understanding is correct, i just thought that SRV can detect whose
server is alive so it can choose and provide an answer with the available
Server.


DNS is not designed to provide this functionality. While technically you can
change contents of DNS depending on which servers are alive and which are
not, it's almost never a good idea.

That means, BIND has nothing like this built in.


On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
 wrote:
> Is DNS Bind SRV record can detect the Server's availability? If yes, how?



On Tue, 5 Jan 2021, 23:53 tale  wrote:

Could you provide more information about your goal?  I don't fully
understand the question.

For my reading, the answer is basically no, in that an SRV record just
provides data about where.a particular service can be found.  It's up
to other systems to fetch that data and interpret it, including
whether that service is actually available at the given endpoint.  In
its typical operation, BIND will just take whatever name and port the
zone administrator said to provide for that SRV record, and not do any
sort of availability checks on it.

However, if you go deep into a far more complicated, custom use of
BIND, you could set up a process that monitors the availability and
changes the SRV record accordingly.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
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: SRV Record Server Availability

[Wilfred Sarmiento via bind-users]

Hi Tale, Happy new year!

Your understanding is correct, i just thought that SRV can detect whose
server is alive so it can choose and provide an answer with the available
Server.

Thank you!



On Tue, 5 Jan 2021, 23:53 tale  wrote:

> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>  wrote:
> > Is DNS Bind SRV record can detect the Server's availability? If yes, how?
>
> Could you provide more information about your goal?  I don't fully
> understand the question.
>
> For my reading, the answer is basically no, in that an SRV record just
> provides data about where.a particular service can be found.  It's up
> to other systems to fetch that data and interpret it, including
> whether that service is actually available at the given endpoint.  In
> its typical operation, BIND will just take whatever name and port the
> zone administrator said to provide for that SRV record, and not do any
> sort of availability checks on it.
>
> However, if you go deep into a far more complicated, custom use of
> BIND, you could set up a process that monitors the availability and
> changes the SRV record accordingly.
> --
> tale
>

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
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