Re: non-improving referral

2021-07-07 Thread Mark Andrews 
This is an old style referral like you would have got out of BIND4
where the referral appears in the answer section.  Note AA is NOT
set so it is not a valid answer to the question.

% dig +norec ns ok.contact @fwd3.dccdns.com

; <<>> DiG 9.15.4 <<>> +norec ns ok.contact @fwd3.dccdns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11820
;; flags: qr ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ok.contact.IN  NS

;; ANSWER SECTION:
ok.contact. 3600IN  NS  fwd1.dns.ws.
ok.contact. 3600IN  NS  fwd3.dns.ws.
ok.contact. 3600IN  NS  fwd2.dns.ws.
ok.contact. 3600IN  NS  fwd4.dns.ws.

;; Query time: 176 msec
;; SERVER: 64.70.78.82#53(64.70.78.82)
;; WHEN: Thu Jul 08 15:09:04 AEST 2021
;; MSG SIZE  rcvd: 121

% 

> On 8 Jul 2021, at 01:03, tale  wrote:
> 
> On Mon, Jul 5, 2021 at 8:20 PM Mark Andrews  wrote:
>> This is an error with the delegation of ok.contact.  The NS records at the 
>> delegation point do
>> not match those at the zone apex.
> 
> I'm curious if this is a re-purposing of the existing "non-improving
> referral" message.  I totally get how that brief phrase makes sense
> for a sideways referral, but I'm not seeing how that statement makes
> sense for ok.contact.
> 
> # Delegation for .contact
> $ dig +noall +auth ns contact @a.root-servers.net
> contact. 172800 IN NS demand.beta.aridns.net.au.
> contact. 172800 IN NS demand.alpha.aridns.net.au.
> contact. 172800 IN NS demand.delta.aridns.net.au.
> contact. 172800 IN NS demand.gamma.aridns.net.au.
> 
> # Delegation for ok.contact
> $ dig +noall +auth ns ok.contact @demand.alpha.aridns.net.au.
> ok.contact. 86400 IN NS fwd2.dccdns.com.
> ok.contact. 86400 IN NS fwd1.dccdns.com.
> ok.contact. 86400 IN NS fwd4.dccdns.com.
> ok.contact. 86400 IN NS fwd3.dccdns.com.
> 
> # Apex NS for ok.contact
> $ dig +noall +ans ns ok.contact @fwd1.dccdns.com
> ok.contact. 3499 IN NS fwd4.dns.ws.
> ok.contact. 3499 IN NS fwd2.dns.ws.
> ok.contact. 3499 IN NS fwd1.dns.ws.
> ok.contact. 3499 IN NS fwd3.dns.ws.
> 
> Yes, the apex NS names aren't the same as the delegating NS (though
> the adb addresses are), but that last one isn't a referral.
> 
> I trust you are right, Mark.  I'm just not sure what I'm missing about
> "non-improving referral".
> -- 
> tale

-- 
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: non-improving referral

2021-07-07 Thread tale via bind-users 
On Mon, Jul 5, 2021 at 8:20 PM Mark Andrews  wrote:
> This is an error with the delegation of ok.contact.  The NS records at the 
> delegation point do
> not match those at the zone apex.

I'm curious if this is a re-purposing of the existing "non-improving
referral" message.  I totally get how that brief phrase makes sense
for a sideways referral, but I'm not seeing how that statement makes
sense for ok.contact.

# Delegation for .contact
$ dig +noall +auth ns contact @a.root-servers.net
contact. 172800 IN NS demand.beta.aridns.net.au.
contact. 172800 IN NS demand.alpha.aridns.net.au.
contact. 172800 IN NS demand.delta.aridns.net.au.
contact. 172800 IN NS demand.gamma.aridns.net.au.

# Delegation for ok.contact
$ dig +noall +auth ns ok.contact @demand.alpha.aridns.net.au.
ok.contact. 86400 IN NS fwd2.dccdns.com.
ok.contact. 86400 IN NS fwd1.dccdns.com.
ok.contact. 86400 IN NS fwd4.dccdns.com.
ok.contact. 86400 IN NS fwd3.dccdns.com.

# Apex NS for ok.contact
$ dig +noall +ans ns ok.contact @fwd1.dccdns.com
ok.contact. 3499 IN NS fwd4.dns.ws.
ok.contact. 3499 IN NS fwd2.dns.ws.
ok.contact. 3499 IN NS fwd1.dns.ws.
ok.contact. 3499 IN NS fwd3.dns.ws.

Yes, the apex NS names aren't the same as the delegating NS (though
the adb addresses are), but that last one isn't a referral.

I trust you are right, Mark.  I'm just not sure what I'm missing about
"non-improving referral".
-- 
tale
___
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: compile flag to disable AAAA responses is unrecognized

2021-07-07 Thread Ondřej Surý 
In such case, just don’t do it. The option was meant was early deployments 
where IPv6 would be utterly broken. This isn’t a case anymore.

FTR the option is now a separate plugin that needs to be loaded first. But as I 
said, just don’t do that, it’s not needed.

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.

> On 7. 7. 2021, at 15:39, Scott Strattner  wrote:
> 
> 
> First, I subscribe to digest so I hope my reply does the right thing and ends 
> up in the thread, apologies otherwise.
>  
> Rick,
>  
> It isn't a critical thing and maybe I am overthinking it, but I want to avoid 
> situations down the road where dual-homed systems target the DNS and prefer 
> the IPv6 reply, when our gateway and internet access is IPv4 only. I'm in a 
> lab that is only IPv4 but could in near future have some pockets of IPv6. 
> Since it seemed to be something I could only do at compile time, I wanted to 
> enable it now just in case.
>  
> Mark,
>  
> Thank you for that plugin info, I'll take a look.
> 
> Message: 3
> Date: Tue, 6 Jul 2021 19:05:49 +
> From: "Scott Strattner" 
> To: bind-users@lists.isc.org
> Subject: compile flag to disable  responses is unrecognized
> Message-ID:
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> An HTML attachment was scrubbed...
> URL: 
>   >
> 
> --
> 
> Message: 4
> Date: Tue, 6 Jul 2021 15:45:37 -0400
> From: Rick Dicaire 
> To: Bind Users Mailing List 
> Subject: Re: compile flag to disable  responses is unrecognized
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
> 
> On Tue, Jul 6, 2021 at 3:06 PM Scott Strattner  wrote:
> 
> > I successfully built 9.16.18 on my RH8.4 ppc64el VM. But after doing so I
> > wanted to set it up so that if it receives a query over IPv4 it will not
> > return any  records in the reply
> >
> 
> Hi Scott, just curious, why do you need this?
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
>   >
> 
> --
> 
> Message: 5
> Date: Wed, 7 Jul 2021 09:57:48 +1000
> From: Mark Andrews 
> To: Scott Strattner 
> Cc: bind-users@lists.isc.org
> Subject: Re: compile flag to disable  responses is unrecognized
> Message-ID: <2b50abb3-57e8-4d8d-9239-52b334679...@isc.org>
> Content-Type: text/plain; charset=us-ascii
> 
>  filtering is now a plug-in (as of 9.14).  This is documented in the ARM.
> ***
>  
> 
> 
> ___
> 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: compile flag to disable AAAA responses is unrecognized

2021-07-07 Thread Scott Strattner 
First, I subscribe to digest so I hope my reply does the right thing and ends up in the thread, apologies otherwise.
 
Rick,
 
It isn't a critical thing and maybe I am overthinking it, but I want to avoid situations down the road where dual-homed systems target the DNS and prefer the IPv6 reply, when our gateway and internet access is IPv4 only. I'm in a lab that is only IPv4 but could in near future have some pockets of IPv6. Since it seemed to be something I could only do at compile time, I wanted to enable it now just in case.
 
Mark,
 
Thank you for that plugin info, I'll take a look.
Message: 3Date: Tue, 6 Jul 2021 19:05:49 +From: "Scott Strattner" To: bind-users@lists.isc.orgSubject: compile flag to disable  responses is unrecognizedMessage-ID:Content-Type: text/plain; charset="us-ascii"An HTML attachment was scrubbed...URL: --Message: 4Date: Tue, 6 Jul 2021 15:45:37 -0400From: Rick Dicaire To: Bind Users Mailing List Subject: Re: compile flag to disable  responses is unrecognizedMessage-ID:Content-Type: text/plain; charset="utf-8"On Tue, Jul 6, 2021 at 3:06 PM Scott Strattner  wrote:> I successfully built 9.16.18 on my RH8.4 ppc64el VM. But after doing so I> wanted to set it up so that if it receives a query over IPv4 it will not> return any  records in the reply>Hi Scott, just curious, why do you need this?-- next part --An HTML attachment was scrubbed...URL: --Message: 5Date: Wed, 7 Jul 2021 09:57:48 +1000From: Mark Andrews To: Scott Strattner Cc: bind-users@lists.isc.orgSubject: Re: compile flag to disable  responses is unrecognizedMessage-ID: <2b50abb3-57e8-4d8d-9239-52b334679...@isc.org>Content-Type: text/plain; charset=us-ascii filtering is now a plug-in (as of 9.14).  This is documented in the ARM.***
 

___
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

query failed (broken trust chain)

2021-07-07 Thread Manish Rane 
Hi Team,

Any clue why this? and I my BIND has stopped resolving

07-Jul-2021 15:59:34.588 client @0x7f1c50b7ea88 192.168.10.174#56213 (
cisco.com): query failed (broken trust chain) for cisco.com/IN/A at
query.c:7376
07-Jul-2021 15:59:34.844 client @0x7f1c5d9135a8 192.168.10.174#56214 (
cisco.com): query failed (broken trust chain) for cisco.com/IN/ at
query.c:73

BIND 9.16.18-Ubuntu (Stable Release) ___
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: non-improving referral

2021-07-07 Thread @lbutlr 
On 2021 Jul 05, at 18:20, Mark Andrews  wrote:
> On 6 Jul 2021, at 06:40, @lbutlr  wrote:
>> DNS format error from 64.70.78.82#53 resolving ok.contact/NS for 
>> 127.0.0.1#16749: non-improving referra
> 
> This is an error with the delegation of ok.contact.  The NS records at the 
> delegation point do not match those at the zone apex.

Ah, thank you. I should have realized that was a domain.

Too many TLDs. Why in my day, in my day there were like 5 and that was good 
enough for everyone! .edu .org .com… Three! There were three! :)

-- 
Like so many Americans, she was trying to construct a life that
made sense from things she found in gift shops.

___
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