From mehmet at akcin.net  Sat Nov  9 06:00:14 2019
From: mehmet at akcin.net (Mehmet Akcin)
Date: Fri, 8 Nov 2019 22:00:14 -0800
Subject: [dns-operations] Root and critical dns server caching
Message-ID: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>

Hey there

I am trying to improve the performance of tlds in various parts of the
world as part of a project.

Besides PCH, who else I can get a hold of these days to have local caches
of DNS? I am focusing on Brazil, Argentina, Peru, Colombia and Chile

Thank you

Mehmet
-- 
Mehmet
+1-424-298-1903
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191108/a9636f53/attachment.html>

From woody at pch.net  Sat Nov  9 08:31:05 2019
From: woody at pch.net (Bill Woodcock)
Date: Sat, 9 Nov 2019 09:31:05 +0100
Subject: [dns-operations] Root and critical dns server caching
In-Reply-To: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
References: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
Message-ID: <B631AB82-2DCE-47A5-8729-7BB7B37B21AE@pch.net>

Verisign are generally responsive, and can get you both root and TLD. 
    
                -Bill


> On Nov 9, 2019, at 07:28, Mehmet Akcin <mehmet at akcin.net> wrote:
> 
> ?
> Hey there
> 
> I am trying to improve the performance of tlds in various parts of the world as part of a project.
> 
> Besides PCH, who else I can get a hold of these days to have local caches of DNS? I am focusing on Brazil, Argentina, Peru, Colombia and Chile
> 
> Thank you
> 
> Mehmet
> -- 
> Mehmet
> +1-424-298-1903
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations




From warren at kumari.net  Sat Nov  9 13:37:43 2019
From: warren at kumari.net (Warren Kumari)
Date: Sat, 9 Nov 2019 08:37:43 -0500
Subject: [dns-operations] Root and critical dns server caching
In-Reply-To: <B631AB82-2DCE-47A5-8729-7BB7B37B21AE@pch.net>
References: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
 <B631AB82-2DCE-47A5-8729-7BB7B37B21AE@pch.net>
Message-ID: <CAHw9_iJmYFUFGDf=fsNsgm-go6Q1Kp7hie3-r=G7TQzeh7nEJg@mail.gmail.com>

On Sat, Nov 9, 2019 at 3:43 AM Bill Woodcock <woody at pch.net> wrote:
>
> Verisign are generally responsive, and can get you both root and TLD.

PCH is also very responsive.

For root -- https://tools.ietf.org/html/rfc7706   -- RFC7706bis should
be published soon -
https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/

W


>
>                 -Bill
>
>
> > On Nov 9, 2019, at 07:28, Mehmet Akcin <mehmet at akcin.net> wrote:
> >
> > ?
> > Hey there
> >
> > I am trying to improve the performance of tlds in various parts of the world as part of a project.
> >
> > Besides PCH, who else I can get a hold of these days to have local caches of DNS? I am focusing on Brazil, Argentina, Peru, Colombia and Chile
> >
> > Thank you
> >
> > Mehmet
> > --
> > Mehmet
> > +1-424-298-1903
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


From dns at jrcs.net  Sat Nov  9 12:56:02 2019
From: dns at jrcs.net (James Stevens)
Date: Sat, 9 Nov 2019 12:56:02 +0000
Subject: [dns-operations] Root and critical dns server caching
In-Reply-To: <B631AB82-2DCE-47A5-8729-7BB7B37B21AE@pch.net>
References: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
 <B631AB82-2DCE-47A5-8729-7BB7B37B21AE@pch.net>
Message-ID: <112505ef-5f2f-5f80-62b2-8c6379fc8dfd@jrcs.net>

CommunityDNS carry quite a few ccTLDs and have an anycast cluster in 
Curitiba

Try contacting paul.kane at cdns.net



James

On 09/11/2019 08:31, Bill Woodcock wrote:
> Verisign are generally responsive, and can get you both root and TLD.
>      
>                  -Bill
> 
> 
>> On Nov 9, 2019, at 07:28, Mehmet Akcin <mehmet at akcin.net> wrote:
>>
>> ?
>> Hey there
>>
>> I am trying to improve the performance of tlds in various parts of the world as part of a project.
>>
>> Besides PCH, who else I can get a hold of these days to have local caches of DNS? I am focusing on Brazil, Argentina, Peru, Colombia and Chile
>>
>> Thank you
>>
>> Mehmet
>> -- 
>> Mehmet
>> +1-424-298-1903
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 

From rubensk at nic.br  Sat Nov  9 21:41:10 2019
From: rubensk at nic.br (Rubens Kuhl)
Date: Sat, 9 Nov 2019 18:41:10 -0300
Subject: [dns-operations] Root and critical dns server caching
In-Reply-To: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
References: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
Message-ID: <5E7F884F-0EBB-4A36-8EF6-730360CC8AAC@nic.br>



> On 9 Nov 2019, at 03:00, Mehmet Akcin <mehmet at akcin.net> wrote:
> 
> Hey there
> 
> I am trying to improve the performance of tlds in various parts of the world as part of a project.
> 
> Besides PCH, who else I can get a hold of these days to have local caches of DNS? I am focusing on Brazil, Argentina, Peru, Colombia and Chile

Mehmet,

NIC.br <http://nic.br/> already runs .br instances in a dozen cities in Brazil, at the same it sponsors server equipment for ICANN to run L-Root in almost the same locations (remember your previous life ? ;-). 
Verisign (http://www.verisigninc.com/rirs <http://www.verisigninc.com/rirs>) also has a few locations in Brazil, and considering root zone, .br and VRSN TLDs, most DNS traffic of interest to Brazilians can be resolved locally. 



Rubens



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191109/50053561/attachment.html>

From mehmet at akcin.net  Sat Nov  9 22:17:42 2019
From: mehmet at akcin.net (Mehmet Akcin)
Date: Sat, 9 Nov 2019 14:17:42 -0800
Subject: [dns-operations] Root and critical dns server caching
In-Reply-To: <5E7F884F-0EBB-4A36-8EF6-730360CC8AAC@nic.br>
References: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
 <5E7F884F-0EBB-4A36-8EF6-730360CC8AAC@nic.br>
Message-ID: <CA+LTh5V1p0qzph3PF0XXaAUFBoJeUF3BOhkbxEiub807ho39pg@mail.gmail.com>

Yes NIC.BR is amazing. I am impressed how much they helped me when I was
ICANN!!

On Sat, Nov 9, 2019 at 13:41 Rubens Kuhl <rubensk at nic.br> wrote:

>
>
> On 9 Nov 2019, at 03:00, Mehmet Akcin <mehmet at akcin.net> wrote:
>
> Hey there
>
> I am trying to improve the performance of tlds in various parts of the
> world as part of a project.
>
> Besides PCH, who else I can get a hold of these days to have local caches
> of DNS? I am focusing on Brazil, Argentina, Peru, Colombia and Chile
>
>
> Mehmet,
>
> NIC.br already runs .br instances in a dozen cities in Brazil, at the
> same it sponsors server equipment for ICANN to run L-Root in almost the
> same locations (remember your previous life ? ;-).
> Verisign (http://www.verisigninc.com/rirs) also has a few locations in
> Brazil, and considering root zone, .br and VRSN TLDs, most DNS traffic of
> interest to Brazilians can be resolved locally.
>
>
>
> Rubens
>
>
>
> --
Mehmet
+1-424-298-1903
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191109/e8793a36/attachment.html>

From lists at mn0.us  Mon Nov 11 01:30:00 2019
From: lists at mn0.us (Matt Nordhoff)
Date: Mon, 11 Nov 2019 01:30:00 +0000
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
Message-ID: <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>

On Wed, Oct 30, 2019 at 11:30 PM Mark Andrews <marka at isc.org> wrote:
> > On 31 Oct 2019, at 12:02 am, Bob Harold <rharolde at umich.edu> wrote:
> > On Tue, Oct 29, 2019 at 9:07 PM Paul Vixie <paul at redbarn.org> wrote:
> > Mark Andrews wrote on 2019-10-27 19:24:
> > > ...
> > >
> > > BIND tried to fix named to reject AA=0 from authoritative servers a
> > > few years back but pandora.tv was returning AA=0 from all servers at
> > > the time and we had to back the change out.  We still want to make
> > > that change.
> >
> > please consider making this a config option so that those of us who are
> > willing to endure outages for nonconforming domains can turn it on. it
> > could even become part of some annual so-called dns flag day.
> >
> > --
> > P Vixie
> >
> > I agree.
> >
> > But if someone thinks that is too drastic, would it be reasonable to make a config option, plus an exception list?   Then someone could make exceptions for the known cases, but break any new cases, to avoid this problem getting any worse.
> >
> > --
> > Bob Harold
>
> First thing is to get Google, Cloudflare etc. on board.  ?But it works using 8.8.8.8 or 1.1.1.1? etc.
> is the biggest problem with actually being able to deploy fixes.  The second problem is being able
> to contact the server administrators.

For y'all's information, PowerDNS Recursor rejects non-AA responses.
It used to accept them until, I believe, earlier this year.

They're tracking broken zones in an issue:

<https://github.com/PowerDNS/pdns/issues/8150>
-- 
Matt Nordhoff


From puneets at google.com  Mon Nov 11 03:41:08 2019
From: puneets at google.com (Puneet Sood)
Date: Sun, 10 Nov 2019 22:41:08 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
Message-ID: <CA+9_gVsG+cy7+2StWPFDT=XjqH8TcQsSb0xXJisN7S10yN56pw@mail.gmail.com>

On Wed, Oct 30, 2019 at 7:31 PM Mark Andrews <marka at isc.org> wrote:
>
>
>
> > On 31 Oct 2019, at 12:02 am, Bob Harold <rharolde at umich.edu> wrote:
> >
> >
> > On Tue, Oct 29, 2019 at 9:07 PM Paul Vixie <paul at redbarn.org> wrote:
> >
> >
> > Mark Andrews wrote on 2019-10-27 19:24:
> > > ...
> > >
> > > BIND tried to fix named to reject AA=0 from authoritative servers a
> > > few years back but pandora.tv was returning AA=0 from all servers at
> > > the time and we had to back the change out.  We still want to make
> > > that change.
> >
> > please consider making this a config option so that those of us who are
> > willing to endure outages for nonconforming domains can turn it on. it
> > could even become part of some annual so-called dns flag day.
> >
> > --
> > P Vixie
> >
> > I agree.
> >
> > But if someone thinks that is too drastic, would it be reasonable to make a config option, plus an exception list?   Then someone could make exceptions for the known cases, but break any new cases, to avoid this problem getting any worse.
> >
> > --
> > Bob Harold
> >
>
> First thing is to get Google, Cloudflare etc. on board.  ?But it works using 8.8.8.8 or 1.1.1.1? etc.
> is the biggest problem with actually being able to deploy fixes.  The second problem is being able
> to contact the server administrators.

Can you file a bug at
https://developers.google.com/speed/public-dns/groups#issues?

> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


From ietf-dane at dukhovni.org  Mon Nov 11 04:32:01 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 10 Nov 2019 23:32:01 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
Message-ID: <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>

> On Nov 10, 2019, at 8:30 PM, Matt Nordhoff <lists at mn0.us> wrote:
> 
> For y'all's information, PowerDNS Recursor rejects non-AA responses.
> It used to accept them until, I believe, earlier this year.
> 
> They're tracking broken zones in an issue:
> 
> <https://github.com/PowerDNS/pdns/issues/8150>

Reading that issue it seems that the servers in question return
cached non-authoritative data even when the request has RD=0,
provided some recent RD=1 query brings the data into the cache.

In which case the issue is not *failing* to set AA=1, but rather
a server that is authoritative for some domains and recursive for
others allowing non-authoritative cached data to leak into RD=0
replies.

How common are such servers?  Is their behaviour incorrect?

-- 
	Viktor.


From liman at netnod.se  Mon Nov 11 12:16:43 2019
From: liman at netnod.se (Lars-Johan Liman)
Date: Mon, 11 Nov 2019 13:16:43 +0100
Subject: [dns-operations] Root and critical dns server caching
In-Reply-To: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
 (Mehmet Akcin's message of "Fri, 8 Nov 2019 22:00:14 -0800")
References: <CA+LTh5WHCmYTjHvMfnycvLijkQ1QFUpfC_tUMyXmeXLjW2_2Mw@mail.gmail.com>
Message-ID: <22o8xitxp0.fsf@floptop.liman.net>

Hi Mehmet!

mehmet at akcin.net:
> I am trying to improve the performance of tlds in various parts of the
> world as part of a project.

> Besides PCH, who else I can get a hold of these days to have local
> caches of DNS? I am focusing on Brazil, Argentina, Peru, Colombia and
> Chile

I (as in me and as in I-root ;-) = Netnod) would be happy to have a
chat. We have some stuff in LatAm and are always looking for more
opportunities.

				Cheers,
				  /Liman

From dot at dotat.at  Mon Nov 11 13:49:15 2019
From: dot at dotat.at (Tony Finch)
Date: Mon, 11 Nov 2019 13:49:15 +0000
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
Message-ID: <alpine.DEB.2.20.1911111339440.10845@grey.csi.cam.ac.uk>

Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> Reading that issue it seems that the servers in question return
> cached non-authoritative data even when the request has RD=0,
> provided some recent RD=1 query brings the data into the cache.

This is normal for recursive servers. Whether this traditional behaviour
is sensible or not is another question. If a recursuve server has mutually
distrusting clients then it's a privacy leak known as DNS cache snooping.

> In which case the issue is not *failing* to set AA=1, but rather
> a server that is authoritative for some domains and recursive for
> others allowing non-authoritative cached data to leak into RD=0
> replies.
>
> How common are such servers?  Is their behaviour incorrect?

Dunno about how common they are. There are two misconfigurations: servers
identified in public NS records should be authoritative for the zone (but
these ones are not) and they should not offer recursion (but these ones
do).

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Humber, Thames: South veering west or southwest, 6 to gale 8. Moderate or
rough. Showers. Good.

From jerry at dns-oarc.net  Mon Nov 11 14:28:57 2019
From: jerry at dns-oarc.net (=?UTF-8?Q?Jerry_Lundstr=c3=b6m?=)
Date: Mon, 11 Nov 2019 15:28:57 +0100
Subject: [dns-operations] RPKI origin validation for resolvers!
Message-ID: <55cab883-2234-e6df-5225-d8f737601804@dns-oarc.net>

Hi all,

Check My DNS [1] can now check if RPKI origin validation is enabled for
the resolvers that queries it.

Download cmdns-cli [2] and run `cmdns-cli -checks trans_rpkiv4`, read
this blog post [3] for more details.

Special thanks to Job Snijders (NTT) for making this possible!

Cheers,
Jerry

[1] <https://cmdns.dev.dns-oarc.net/>
[2] <https://github.com/DNS-OARC/cmdns-cli>
[3]
<https://medium.com/@dnsoarc/rpki-origin-validation-for-resolvers-c4463f1cb9a6>

From js at jrcs.net  Mon Nov 11 14:44:08 2019
From: js at jrcs.net (James Stevens)
Date: Mon, 11 Nov 2019 14:44:08 +0000
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
Message-ID: <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>

On a different, but related topic ...

Would it be reasonable for an authoritative-only DNS Server to reject / 
ignore / throttle requests with RD=1 ?

Of course, this will cause issues with debugging as "dig" sets "RD=1" by 
default and it would be extremely common to forget to add "+norec", but 
a "correct" resolver shouldn't be sending RD=1 to authoritative servers, 
right?



James

From fweimer at redhat.com  Mon Nov 11 15:17:07 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 11 Nov 2019 16:17:07 +0100
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net> (James Stevens's
 message of "Mon, 11 Nov 2019 14:44:08 +0000")
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
Message-ID: <87a792wih8.fsf@oldenburg2.str.redhat.com>

* James Stevens:

> Would it be reasonable for an authoritative-only DNS Server to reject
> / ignore / throttle requests with RD=1 ?

It confuses people who try to debug issues with the dig tool.  Some
servers already do it.

Some system adminstrators want to list authoritative name servers in
/etc/resolv.conf for some reason, and that would break too.

Thanks,
Florian



From paul at redbarn.org  Mon Nov 11 15:51:52 2019
From: paul at redbarn.org (Paul Vixie)
Date: Mon, 11 Nov 2019 07:51:52 -0800
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <87a792wih8.fsf@oldenburg2.str.redhat.com>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
Message-ID: <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>



Florian Weimer wrote on 2019-11-11 07:17:
> * James Stevens:
> 
>> Would it be reasonable for an authoritative-only DNS Server to reject
>> / ignore / throttle requests with RD=1 ?
> 
> It confuses people who try to debug issues with the dig tool.  Some
> servers already do it.
> 
> Some system adminstrators want to list authoritative name servers in
> /etc/resolv.conf for some reason, and that would break too.

when presented with a choice of what to break, i find the best way 
forward to be, break something highly visible, and break it early.

so, answering REFUSED when authoritative-only and receiving RD=1, and 
answering REFUSED when recursive-only and receiving RD=0, and treating 
AA=0 as "lame" when doing recursion, all lead to a choppy present but a 
smoother future.

-- 
P Vixie


From paul at redbarn.org  Mon Nov 11 16:01:03 2019
From: paul at redbarn.org (Paul Vixie)
Date: Mon, 11 Nov 2019 08:01:03 -0800
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
Message-ID: <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>



Viktor Dukhovni wrote on 2019-11-10 20:32:
>> ...
>>
>> <https://github.com/PowerDNS/pdns/issues/8150>
> 
> Reading that issue it seems that the servers in question return
> cached non-authoritative data even when the request has RD=0,
> provided some recent RD=1 query brings the data into the cache.
> 
> In which case the issue is not *failing* to set AA=1, but rather
> a server that is authoritative for some domains and recursive for
> others allowing non-authoritative cached data to leak into RD=0
> replies.
> 
> How common are such servers?  Is their behaviour incorrect?

we called this bug "bind8" and before that "bind4", which when operating 
in authoritative + recursive mode, because it kept all data no matter 
where it came from in a single tree. a decade was spent trying to tag 
things to prevent leaks of recursive data into authoritative answers.

the fix was called "bind9" which does not leak in this way.

there's also a general trend to authoritative-only and recursive-only, 
rather than doing both in one name server, even though modern name 
servers (not just bind9) no longer leak.

-- 
P Vixie


From jabley at hopcount.ca  Mon Nov 11 16:37:26 2019
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 11 Nov 2019 11:37:26 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
Message-ID: <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>

On 11 Nov 2019, at 11:01, Paul Vixie <paul at redbarn.org> wrote:

> the fix was called "bind9" which does not leak in this way.

Perhaps I'm misunderstanding what you mean by "in this way"?

https://www.dns-oarc.net/oarc/services/odvr

jabley at anchovy ~ % dig @184.105.193.73 version.bind ch txt +short
"9.12.1"
jabley at anchovy ~ % dig @184.105.193.73 hopcount.ca mx +short +rec
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.
jabley at anchovy ~ % dig @184.105.193.73 hopcount.ca mx +short +norec
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.
jabley at anchovy ~ % 


Joe


From ietf-dane at dukhovni.org  Mon Nov 11 19:11:31 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Nov 2019 14:11:31 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
 <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
Message-ID: <20191111191131.GT34850@straasha.imrryr.org>

On Mon, Nov 11, 2019 at 11:37:26AM -0500, Joe Abley wrote:

> https://www.dns-oarc.net/oarc/services/odvr
> 
> jabley at anchovy ~ % dig @184.105.193.73 version.bind ch txt +short
> "9.12.1"
>
> jabley at anchovy ~ % dig @184.105.193.73 hopcount.ca mx +short +rec
> 1 aspmx.l.google.com.
> 5 alt1.aspmx.l.google.com.
> 5 alt2.aspmx.l.google.com.
> 10 alt3.aspmx.l.google.com.
> 10 alt4.aspmx.l.google.com.
> jabley at anchovy ~ % dig @184.105.193.73 hopcount.ca mx +short +norec
> 1 aspmx.l.google.com.
> 5 alt1.aspmx.l.google.com.
> 5 alt2.aspmx.l.google.com.
> 10 alt3.aspmx.l.google.com.
> 10 alt4.aspmx.l.google.com.
> jabley at anchovy ~ % 

I can confirm the "leak", a second non-recursive query returns
cached data after an intermediate recursive query

 1. RD=0, response is a referral

    $ hsdig -R -t mx -n 184.105.193.73 ????????.org
    org. IN NS a0.org.afilias-nst.info.
    org. IN NS a2.org.afilias-nst.info.
    org. IN NS b0.org.afilias-nst.org.
    org. IN NS b2.org.afilias-nst.org.
    org. IN NS c0.org.afilias-nst.info.
    org. IN NS d0.org.afilias-nst.org.

 2. RD=1
    $ hsdig -t mx -n 184.105.193.73 ????????.org
    xn--b1adqpd3ao5c.org. IN MX 0 smtp.dukhovni.org. ; NoError AD=1

 3. RD=0 again, but now a cached answer and zone-apex NS RRs
    $ hsdig -R -t mx -n 184.105.193.73 ????????.org
    xn--b1adqpd3ao5c.org. IN MX 0 smtp.dukhovni.org. ; NoError AD=1
    xn--b1adqpd3ao5c.org. IN NS nsa.dukhovni.org. ; AD=1
    xn--b1adqpd3ao5c.org. IN NS nsb.imrryr.org. ; AD=1

[ In case you're wondering, hsdig[1] is a tool I wrote for my own
  use, it is a light-weight CLI for the Haskell DNS library. ]

-- 
	Viktor.

[1] Unlike "dig", "hsdig" can perform queries for multiple domains
concurrently, so its primary use-case is bulk queries. But, I also
find the "-z" option convenient for querying glue.  Its SOA mrname
is more friendly, with "@" instead of a dot after the first label,
in which any literal dots are then not escaped:

    $ hsdig -t soa army.mil
    army.mil. IN SOA ns01.army.mil. usarmy.huachuca.netcom.mesg.epdns-global at mail.mil. ...

    $ hsdig --help
    hsdig - parallel DNS client

    Usage: hsdig [-t|--type RRTYPE] [-z|--zone ZONE]
		 [-N | (-n|--nameserver ADDRESS)] [-p|--prefix PREFIX]
		 [-T|--timeout T] [-r|--tries N] [-m|--threads N] [-C|--cd]
		 [-R|--rd] [-u|--udpsize BYTES] [-D|--dnssec] [DOMAIN...]

    Available options:
      -h,--help                Show this help text
      -t,--type RRTYPE         The query RRTYPE, as a supported name or a
			       number (default: A)
      -z,--zone ZONE           Query authoritative nameservers of ZONE
      -N                       Use nameservers listed in /etc/resolv.conf
      -n,--nameserver ADDRESS  Use nameserver at ADDRESS (default: "127.0.0.1")
      -p,--prefix PREFIX       Optionally prepend 'PREFIX.' to each domain
      -T,--timeout T           Set DNS request timeout to T ms (default: 3000ms)
      -r,--tries N             Make at most N DNS requests per lookup (default: 6)
      -m,--threads N           Set thread count to N (default: 50)
      -C,--cd                  Request unvalidated data
      -R,--rd                  Issue a non-recursive query
      -u,--udpsize BYTES       Set EDNS UDP buffer size to BYTES (default: 8192)
      -D,--dnssec              Request DNSSEC records
      DOMAIN...                DOMAINs to scan, read from stdin by default

The default EDNS buffer size is 8192 bytes because the default
resolver is 127.0.0.1.  With "-z", the buffer size defaults to
1232 bytes.

From tale at dd.org  Mon Nov 11 19:36:09 2019
From: tale at dd.org (Dave Lawrence)
Date: Mon, 11 Nov 2019 14:36:09 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
Message-ID: <24009.47145.217776.427770@gro.dd.org>

Paul Vixie writes:
> so, answering REFUSED when authoritative-only and receiving RD=1, and 
> answering REFUSED when recursive-only and receiving RD=0, and treating 
> AA=0 as "lame" when doing recursion, all lead to a choppy present but a 
> smoother future.

The third one seems distinctly different to me than the first two.
How do changing those behaviours to a better future?

In the first, RD=1 is merely useless so there's really no reason to be
a busy-body about it.  In the second, RD=0 is a reasonable way to
query the state of the cache without changing it, and one I have
personally found use for in my own debugging.  Both of them are
standards-reasonable ways to 

In the last, AA=0 is a clear standards-noncompliant signalling failure
for which it is entirely appropriate to treat the responder as lame.
(OTOH, if the data can be DNSSEC-validated, hey then whatever, AA was
just redundant -- the data was authoritative even if the responder wasn't.)





From ietf-dane at dukhovni.org  Mon Nov 11 19:57:21 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Nov 2019 14:57:21 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <24009.47145.217776.427770@gro.dd.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
 <24009.47145.217776.427770@gro.dd.org>
Message-ID: <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>

> On Nov 11, 2019, at 2:36 PM, Dave Lawrence <tale at dd.org> wrote:
> 
> In the last, AA=0 is a clear standards-noncompliant signalling failure
> for which it is entirely appropriate to treat the responder as lame.
> (OTOH, if the data can be DNSSEC-validated, hey then whatever, AA was
> just redundant -- the data was authoritative even if the responder wasn't.)

But if the responder is authoritative only for a parent of the requested
domain, and is willing to do recursion for the child zone, and has the
answer cached, then if it also serves data from the cache with RD=0, it
will return AA=0 for the cached data, while the requestor believes the
server to be authoritative (for at least the top of the subtree).

And that's the situation in the PowerDNS issue, and it is not clear to
me that response violates any standards.

We can't have both of:

   * It is valid to return non-authoritative cached data for RD=0
   * It is invalid to return AA=0 in response to RD=0 requests.

Which shall it be? You say you find the first useful, but then you
really can't have the second, the responser isn't necessarily lame
if the qname is not the zone apex.

-- 
	Viktor.


From tale at dd.org  Mon Nov 11 21:11:25 2019
From: tale at dd.org (Dave Lawrence)
Date: Mon, 11 Nov 2019 16:11:25 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
 <24009.47145.217776.427770@gro.dd.org>
 <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
Message-ID: <24009.52861.756127.290495@gro.dd.org>

Viktor Dukhovni writes:
> We can't have both of:
> 
>    * It is valid to return non-authoritative cached data for RD=0
>    * It is invalid to return AA=0 in response to RD=0 requests.
> 
> Which shall it be? You say you find the first useful, but then you
> really can't have the second, the responser isn't necessarily lame
> if the qname is not the zone apex.

When I get an RD=0 query at my dual authoritative/recursive server
that can be answered from authoritative data, I do so without ever
consulting the cache.  

Yes it is a tiny bit sad-making that this means that in the rare case
where I am working with a zone hosted on a dual-mode server that
delegates a subzone away then I don't see the exact same behavior as I
would see in other circumstances, but I'm okay with that.

(Apologies for the poor editing of my previous message, too.  Clearly
I had hit send too soon.)

From marka at isc.org  Mon Nov 11 21:41:56 2019
From: marka at isc.org (Mark Andrews)
Date: Tue, 12 Nov 2019 08:41:56 +1100
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
 <24009.47145.217776.427770@gro.dd.org>
 <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
Message-ID: <7CE1BC39-1428-434E-A6A4-597A160B6C67@isc.org>



> On 12 Nov 2019, at 06:57, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
>> On Nov 11, 2019, at 2:36 PM, Dave Lawrence <tale at dd.org> wrote:
>> 
>> In the last, AA=0 is a clear standards-noncompliant signalling failure
>> for which it is entirely appropriate to treat the responder as lame.
>> (OTOH, if the data can be DNSSEC-validated, hey then whatever, AA was
>> just redundant -- the data was authoritative even if the responder wasn't.)
> 
> But if the responder is authoritative only for a parent of the requested
> domain, and is willing to do recursion for the child zone, and has the
> answer cached, then if it also serves data from the cache with RD=0, it
> will return AA=0 for the cached data, while the requestor believes the
> server to be authoritative (for at least the top of the subtree).
> 
> And that's the situation in the PowerDNS issue, and it is not clear to
> me that response violates any standards.
> 
> We can't have both of:
> 
>   * It is valid to return non-authoritative cached data for RD=0
>   * It is invalid to return AA=0 in response to RD=0 requests.
> 
> Which shall it be? You say you find the first useful, but then you
> really can't have the second, the responser isn't necessarily lame
> if the qname is not the zone apex.

This is a corner case for which there is no explicit signalling in the
query.  There is decades old advice not to be configured as a recursive
server if you are listed as authoritative for a zone (been delegated to)
because it creates such corner cases.

If we want to solve this one needs to add more signalling.  Using AA=1 in the
QUERY to signal that you don?t want to see answers from the cache would be a
logical way to do this and would allow the client to say what it wants from the
server.  One should, in theory, be able to send AA=1 in queries today without
causing problems as it is supposed to be ignored.  The question then becomes
when do you stop inferring no cache access from RD=0, AA=0 queries when you
are willing to recurse for the client.

Mark

> -- 
> 	Viktor.
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org



From ietf-dane at dukhovni.org  Mon Nov 11 22:54:31 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Nov 2019 17:54:31 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <7CE1BC39-1428-434E-A6A4-597A160B6C67@isc.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
 <24009.47145.217776.427770@gro.dd.org>
 <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
 <7CE1BC39-1428-434E-A6A4-597A160B6C67@isc.org>
Message-ID: <E10BD87A-1C6B-41E6-8EC8-1B4A95FB1F62@dukhovni.org>



> On Nov 11, 2019, at 4:41 PM, Mark Andrews <marka at isc.org> wrote:
> 
>> We can't have both of:
>> 
>>  * It is valid to return non-authoritative cached data for RD=0
>>  * It is invalid to return AA=0 in response to RD=0 requests.
>> 
>> Which shall it be? You say you find the first useful, but then you
>> really can't have the second, the responser isn't necessarily lame
>> if the qname is not the zone apex.
> 
> This is a corner case for which there is no explicit signalling in the
> query.  There is decades old advice not to be configured as a recursive
> server if you are listed as authoritative for a zone (been delegated to)
> because it creates such corner cases.

Yes, exactly.  But sadly there are still some servers that are configured as
both, and so resolvers must continue to tolerate "unexpected" AA=0.

> If we want to solve this one needs to add more signalling.  Using AA=1 in the
> QUERY to signal that you don?t want to see answers from the cache would be a
> logical way to do this and would allow the client to say what it wants from the
> server.  One should, in theory, be able to send AA=1 in queries today without
> causing problems as it is supposed to be ignored.  The question then becomes
> when do you stop inferring no cache access from RD=0, AA=0 queries when you
> are willing to recurse for the client.

Sure, and the proposed signal makes sense, but this is not presently
defined, and therefore, concluding AA=0 => lame is not currently possible
except perhaps when qname == zone apex.

We'd first have to determine whether sending AA=1 in queries causes any
middle-box issues or unexpected nameserver behaviour, and then take
a decade to wait for the servers to honour the signal.

In practice it may be simpler to encourage operators to avoid mixed-mode
servers.  Perhaps BIND9's named could evolve to only support one of the
operating modes at a time, and the same with Microsoft DNS, ...  If you
want to do both pick a separate IP address for each.

If the two are never mixed the AA=1 signal in queries is not needed.

-- 
	Viktor.



From marka at isc.org  Tue Nov 12 00:26:13 2019
From: marka at isc.org (Mark Andrews)
Date: Tue, 12 Nov 2019 11:26:13 +1100
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <E10BD87A-1C6B-41E6-8EC8-1B4A95FB1F62@dukhovni.org>
References: <E10BD87A-1C6B-41E6-8EC8-1B4A95FB1F62@dukhovni.org>
Message-ID: <D4CD786F-AE89-4841-AA6D-FE9CF5DB4137@isc.org>

Named behaves as authoritative only when RD=0.

In practice there are only a small number of servers that are listed as authoritative, have recursion enabled and have sub zones of those authoritative zones that they don?t also serve and don?t fallback to being authoritative on RD=0. 

-- 
Mark Andrews

> On 12 Nov 2019, at 10:05, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> ?
> 
>>> On Nov 11, 2019, at 4:41 PM, Mark Andrews <marka at isc.org> wrote:
>>> 
>>> We can't have both of:
>>> 
>>> * It is valid to return non-authoritative cached data for RD=0
>>> * It is invalid to return AA=0 in response to RD=0 requests.
>>> 
>>> Which shall it be? You say you find the first useful, but then you
>>> really can't have the second, the responser isn't necessarily lame
>>> if the qname is not the zone apex.
>> 
>> This is a corner case for which there is no explicit signalling in the
>> query.  There is decades old advice not to be configured as a recursive
>> server if you are listed as authoritative for a zone (been delegated to)
>> because it creates such corner cases.
> 
> Yes, exactly.  But sadly there are still some servers that are configured as
> both, and so resolvers must continue to tolerate "unexpected" AA=0.
> 
>> If we want to solve this one needs to add more signalling.  Using AA=1 in the
>> QUERY to signal that you don?t want to see answers from the cache would be a
>> logical way to do this and would allow the client to say what it wants from the
>> server.  One should, in theory, be able to send AA=1 in queries today without
>> causing problems as it is supposed to be ignored.  The question then becomes
>> when do you stop inferring no cache access from RD=0, AA=0 queries when you
>> are willing to recurse for the client.
> 
> Sure, and the proposed signal makes sense, but this is not presently
> defined, and therefore, concluding AA=0 => lame is not currently possible
> except perhaps when qname == zone apex.
> 
> We'd first have to determine whether sending AA=1 in queries causes any
> middle-box issues or unexpected nameserver behaviour, and then take
> a decade to wait for the servers to honour the signal.
> 
> In practice it may be simpler to encourage operators to avoid mixed-mode
> servers.  Perhaps BIND9's named could evolve to only support one of the
> operating modes at a time, and the same with Microsoft DNS, ...  If you
> want to do both pick a separate IP address for each.
> 
> If the two are never mixed the AA=1 signal in queries is not needed.
> 
> -- 
>    Viktor.
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



From ietf-dane at dukhovni.org  Tue Nov 12 01:06:41 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Nov 2019 20:06:41 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <D4CD786F-AE89-4841-AA6D-FE9CF5DB4137@isc.org>
References: <E10BD87A-1C6B-41E6-8EC8-1B4A95FB1F62@dukhovni.org>
 <D4CD786F-AE89-4841-AA6D-FE9CF5DB4137@isc.org>
Message-ID: <D2F662D7-FC52-4094-9681-3B02D6527193@dukhovni.org>

> 
> On Nov 11, 2019, at 7:26 PM, Mark Andrews <marka at isc.org> wrote:
> 
> Named behaves as authoritative only when RD=0.

[ I parse that to read: "as authoritative-only, when RD=0",
  rather than: "as authoritative, only when RD=0". ]

I think that's also the point that Paul Vixie was making about BIND9,
and yet, DNS-OARC's "odvr" server claims to bind BIND9, but serves
non-authoritative cached data even when RD=0.  I am don't know how to
reconcile the observed behaviour with the expected behaviour reported
by you and Paul.

-- 
	Viktor.



From dot at dotat.at  Tue Nov 12 12:29:45 2019
From: dot at dotat.at (Tony Finch)
Date: Tue, 12 Nov 2019 12:29:45 +0000
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
Message-ID: <alpine.DEB.2.20.1911121222070.10845@grey.csi.cam.ac.uk>

James Stevens <js at jrcs.net> wrote:
>
> Would it be reasonable for an authoritative-only DNS Server to reject / ignore
> / throttle requests with RD=1 ?

I think for quite a long time my toy DNS server (which runs with an
appalling hodge-podge of patches) was running with a config something
like...

view rec {
	match-recursive-only yes;
	# stuff
};
view auth {
	recursion no;
	allow-recursion { none; };
	zone dotat.at { /* ... */ );
	# etc.
};

The effect was that recursive queries went to the rec view then got
rejected by an ACL; RD=0 queries went to the auth view which served my
zone to all comers. The only problem I noticed was RD=1 health checks from
one of my secondaries. My config now has a match-clients clause in the rec
view which works better all round.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
promote human rights and open government

From dot at dotat.at  Tue Nov 12 12:35:47 2019
From: dot at dotat.at (Tony Finch)
Date: Tue, 12 Nov 2019 12:35:47 +0000
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
 <24009.47145.217776.427770@gro.dd.org>
 <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
Message-ID: <alpine.DEB.2.20.1911121233500.10845@grey.csi.cam.ac.uk>

Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> We can't have both of:
>
>    * It is valid to return non-authoritative cached data for RD=0
>    * It is invalid to return AA=0 in response to RD=0 requests.

Well, your server can have both if it allows different clients to get one
or the other :-) You can control this with things like an
allow-query-cache ACL.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: North backing northwest, 4 to 6, increasing 7 at times. Moderate or
rough, becoming very rough in north. Fair. Good.

From dns at jrcs.net  Tue Nov 12 12:53:18 2019
From: dns at jrcs.net (James Stevens)
Date: Tue, 12 Nov 2019 12:53:18 +0000
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <alpine.DEB.2.20.1911121222070.10845@grey.csi.cam.ac.uk>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <alpine.DEB.2.20.1911121222070.10845@grey.csi.cam.ac.uk>
Message-ID: <65e7b54a-2afe-44b4-dc81-ae96dc183564@jrcs.net>

Health-checks (e.g. pingdom etc) with RD=1 seem pretty common.

Really you want to health-check authoritative-only servers respond when 
RD=0 and the response has AA=1, otherwise you might just be hitting a 
resolver, but I guess that's beyond what most of those services provide.

I catch the RD=1 in iptables using m32 and throttle it to (say) 20 per 
second to get round this issue - cos I'm also one of those who keep 
forgetting to add "+norec" to dig :)

Apart from health-checks & dig, most of the RD=1 traffic I get to my 
auth-only servers seems to come from malware, spammers etc - e.g. same 
IP asking the same question 100s of times.


James

On 12/11/2019 12:29, Tony Finch wrote:
> James Stevens <js at jrcs.net> wrote:
>>
>> Would it be reasonable for an authoritative-only DNS Server to reject / ignore
>> / throttle requests with RD=1 ?
> 
> I think for quite a long time my toy DNS server (which runs with an
> appalling hodge-podge of patches) was running with a config something
> like...
> 
> view rec {
> 	match-recursive-only yes;
> 	# stuff
> };
> view auth {
> 	recursion no;
> 	allow-recursion { none; };
> 	zone dotat.at { /* ... */ );
> 	# etc.
> };
> 
> The effect was that recursive queries went to the rec view then got
> rejected by an ACL; RD=0 queries went to the auth view which served my
> zone to all comers. The only problem I noticed was RD=1 health checks from
> one of my secondaries. My config now has a match-clients clause in the rec
> view which works better all round.
> 
> Tony.
> 

From fweimer at redhat.com  Tue Nov 12 13:30:00 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 12 Nov 2019 14:30:00 +0100
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <65e7b54a-2afe-44b4-dc81-ae96dc183564@jrcs.net> (James Stevens's
 message of "Tue, 12 Nov 2019 12:53:18 +0000")
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <alpine.DEB.2.20.1911121222070.10845@grey.csi.cam.ac.uk>
 <65e7b54a-2afe-44b4-dc81-ae96dc183564@jrcs.net>
Message-ID: <87mud1p6hz.fsf@oldenburg2.str.redhat.com>

* James Stevens:

> Health-checks (e.g. pingdom etc) with RD=1 seem pretty common.

They do not work reliably because failure rates for some large
authoritative servers with RD=1 are significantly higher than with RD=0
(or at least were about ten years ago).  I remember a bug in monitoring
software which reported sporadic failure for perfectly healthy servers,
and it turned out that the cause was a bug where the software sent RD=1
queries instead of RD=0 queries.  The failure was stochastic, though.
It oculd have been software or configuration divergence a cluster behind
a load balancer But if I recall correctly, the failure rate was quite a
bit lower than that, so there was probably another factor involved.

Thanks,
Florian



From rharolde at umich.edu  Tue Nov 12 14:47:09 2019
From: rharolde at umich.edu (Bob Harold)
Date: Tue, 12 Nov 2019 09:47:09 -0500
Subject: [dns-operations] Monitoring DNS BIND with SNMP ?
Message-ID: <CA+nkc8C2seWb0RD8YfiJyx=0=GO7sth3kEF3oOi8R4MeB-7Jtg@mail.gmail.com>

Does anyone have recommendations for monitoring BIND with SNMP ?  I don't
seem to find anything from ISC, and not much else on the web that looks
good.

I specifically need to monitor the query rate (a mistake on a cluster with
thousands of nodes can make a DNS server very busy).

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191112/7513fae5/attachment.html>

From alex at mordormx.net  Tue Nov 12 15:25:58 2019
From: alex at mordormx.net (Alejandro Flores)
Date: Tue, 12 Nov 2019 09:25:58 -0600
Subject: [dns-operations] Monitoring DNS BIND with SNMP ?
In-Reply-To: <CA+nkc8C2seWb0RD8YfiJyx=0=GO7sth3kEF3oOi8R4MeB-7Jtg@mail.gmail.com>
References: <CA+nkc8C2seWb0RD8YfiJyx=0=GO7sth3kEF3oOi8R4MeB-7Jtg@mail.gmail.com>
Message-ID: <CAEPLxq-RgHWUebANHrSZKKm=+_2YtLpXiZHACUaYUhn64mVaJg@mail.gmail.com>

mmm i would suggest to use rndc stats executed as extend snmp or a more
complex solution as mentioned on this url
https://computingforgeeks.com/how-to-monitor-bind-dns-server-with-prometheus-and-grafana/


personally i prefer the snmp extended.
just modify the */etc/snmp/snmpd.conf*

add a line like

extend snmpd_status /bin/bash /root/myscript.sh

restart snmpd

snmpwalk -v 2c -c public -O e 127.0.0.1 NET-SNMP-EXTEND-MIB::nsExtendObjects


replace /root/myscript.sh with the command to get the stat you want  " rndc
stats" with awk or sed to filter the number you want.

Regards!
Alejandro Flores L.


On Tue, Nov 12, 2019 at 9:02 AM Bob Harold <rharolde at umich.edu> wrote:

> Does anyone have recommendations for monitoring BIND with SNMP ?  I don't
> seem to find anything from ISC, and not much else on the web that looks
> good.
>
> I specifically need to monitor the query rate (a mistake on a cluster with
> thousands of nodes can make a DNS server very busy).
>
> --
> Bob Harold
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
Alejandro Flores L.
LIA. CEH. VCP.
5513998178
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191112/2acc39bd/attachment.html>

From jake.zack at cira.ca  Tue Nov 12 18:01:33 2019
From: jake.zack at cira.ca (Jake Zack)
Date: Tue, 12 Nov 2019 18:01:33 +0000
Subject: [dns-operations] [EXT]  Monitoring DNS BIND with SNMP ?
In-Reply-To: <CA+nkc8C2seWb0RD8YfiJyx=0=GO7sth3kEF3oOi8R4MeB-7Jtg@mail.gmail.com>
References: <CA+nkc8C2seWb0RD8YfiJyx=0=GO7sth3kEF3oOi8R4MeB-7Jtg@mail.gmail.com>
Message-ID: <0b5a381804cc4e1e852f3818275b990c@cira.ca>

Years ago, before we?d implemented DSC for measuring query loads, I?d setup something along the lines of?


1)      Perl script runs?

a.       Reads in last intervals query number total

b.       Runs ?rndc stats?

c.       Reads in this intervals query number total

d.       Subtracts one from the other (you need to handle BIND restarts, though.  If $current < $last then disregard?otherwise it makes graphs useless due to insane values)

e.       Saves this intervals delta to a file

2)      Snmp custom object id reads that file

a.       Used for Nagios monitoring (if less than $x or more than $y, alert with exit(2))

b.       Used for Cacti graphing

We?d written a draft a while back to try to encourage a standard for DNS software implementers to add SNMP hooks directly into things like query counts, but it never gained traction.

-Jacob Zack
DNS Architect ? CIRA (.CA TLD)

From: dns-operations <dns-operations-bounces at dns-oarc.net> On Behalf Of Bob Harold
Sent: November 12, 2019 9:47 AM
To: dns-operations at lists.dns-oarc.net
Subject: [EXT] [dns-operations] Monitoring DNS BIND with SNMP ?

Does anyone have recommendations for monitoring BIND with SNMP ?  I don't seem to find anything from ISC, and not much else on the web that looks good.

I specifically need to monitor the query rate (a mistake on a cluster with thousands of nodes can make a DNS server very busy).

--
Bob Harold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191112/99ac9466/attachment-0001.html>

From dot at dotat.at  Tue Nov 12 18:27:14 2019
From: dot at dotat.at (Tony Finch)
Date: Tue, 12 Nov 2019 18:27:14 +0000
Subject: [dns-operations] [EXT]  Monitoring DNS BIND with SNMP ?
In-Reply-To: <0b5a381804cc4e1e852f3818275b990c@cira.ca>
References: <CA+nkc8C2seWb0RD8YfiJyx=0=GO7sth3kEF3oOi8R4MeB-7Jtg@mail.gmail.com>
 <0b5a381804cc4e1e852f3818275b990c@cira.ca>
Message-ID: <alpine.DEB.2.20.1911121821340.10845@grey.csi.cam.ac.uk>

Jake Zack <jake.zack at cira.ca> wrote:
>
> 1)      Perl script runs?
>
> a.       Reads in last intervals query number total
>
> b.       Runs ?rndc stats?
>
> c.       Reads in this intervals query number total
>
> d.  Subtracts one from the other (you need to handle BIND restarts,
> though.  If $current < $last then disregard?otherwise it makes graphs
> useless due to insane values)
>
> e.       Saves this intervals delta to a file

I use the statistics server for this: it is less janky than reading the
statistics file and can be fetched remotely. The output from
http://server:8053/json/v1/server is about 10KB and usually has the info I
need, e.g. opcodes.QUERY, nsstats.QryTCP, nsstats.QryUDP, boot-time (for
detecting restarts).

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
harness technological change to human advantage

From nick at intronic.org  Tue Nov 12 18:43:41 2019
From: nick at intronic.org (Nicholas Chappell)
Date: Tue, 12 Nov 2019 10:43:41 -0800
Subject: [dns-operations] [EXT]  Monitoring DNS BIND with SNMP ?
In-Reply-To: <alpine.DEB.2.20.1911121821340.10845@grey.csi.cam.ac.uk>
References: <CA+nkc8C2seWb0RD8YfiJyx=0=GO7sth3kEF3oOi8R4MeB-7Jtg@mail.gmail.com>
 <0b5a381804cc4e1e852f3818275b990c@cira.ca>
 <alpine.DEB.2.20.1911121821340.10845@grey.csi.cam.ac.uk>
Message-ID: <B16436C9-101F-4679-B4EB-B73420C9E203@intronic.org>

I'll second the recommendation for the stats channel/port, but will also suggest a few other tools that can help with the query rate issue.

This little project can parse the XML output from the stats channel and make it available on an HTTP endpoint in Prometheus format:

https://github.com/digitalocean/bind_exporter

>From there, you can point Prometheus at it to get the data and chart/query/alert on it: https://prometheus.io/

Prometheus has a built-in grapher, but it's really basic. Grafana can chart data from a Prometheus server and is much more full-featured: https://grafana.com/

> On Nov 12, 2019, at 10:27 AM, Tony Finch <dot at dotat.at> wrote:
> 
> Jake Zack <jake.zack at cira.ca> wrote:
>> 
>> 1)      Perl script runs?
>> 
>> a.       Reads in last intervals query number total
>> 
>> b.       Runs ?rndc stats?
>> 
>> c.       Reads in this intervals query number total
>> 
>> d.  Subtracts one from the other (you need to handle BIND restarts,
>> though.  If $current < $last then disregard?otherwise it makes graphs
>> useless due to insane values)
>> 
>> e.       Saves this intervals delta to a file
> 
> I use the statistics server for this: it is less janky than reading the
> statistics file and can be fetched remotely. The output from
> http://server:8053/json/v1/server is about 10KB and usually has the info I
> need, e.g. opcodes.QUERY, nsstats.QryTCP, nsstats.QryUDP, boot-time (for
> detecting restarts).
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> harness technological change to human advantage_______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



From paul at redbarn.org  Tue Nov 12 19:32:00 2019
From: paul at redbarn.org (Paul Vixie)
Date: Tue, 12 Nov 2019 11:32:00 -0800
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
 <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
Message-ID: <4c791565-1b64-7c3e-f98b-8708aeffbf5a@redbarn.org>



Joe Abley wrote on 2019-11-11 08:37:
> On 11 Nov 2019, at 11:01, Paul Vixie <paul at redbarn.org> wrote:
> 
>> the fix was called "bind9" which does not leak in this way.
> 
> Perhaps I'm misunderstanding what you mean by "in this way"?

in context, the leak i was talking about was the use of recursive data 
in authoritative answers, coming from servers configured for both.

also note, being able to verify something with dnssec does not make it 
equal to authoritative data, because the TTL won't be the original.

-- 
P Vixie


From ietf-dane at dukhovni.org  Tue Nov 12 23:26:00 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 12 Nov 2019 18:26:00 -0500
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <4c791565-1b64-7c3e-f98b-8708aeffbf5a@redbarn.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
 <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
 <4c791565-1b64-7c3e-f98b-8708aeffbf5a@redbarn.org>
Message-ID: <99C36EB7-C4C6-4F78-A722-2658586E2275@dukhovni.org>

> On Nov 12, 2019, at 2:32 PM, Paul Vixie <paul at redbarn.org> wrote:
> 
> In context, the leak I was talking about was the use of recursive data
> in authoritative answers, coming from servers configured for both.

Can you be more explicit about what you mean by "in authoritative
answers"?  Do you mean answers to queries with "RD=0", or answers
with "AA=1"?

It seems that a dual-mode BIND9 server does return recursive data
in answer to queries with "RD=0", but such answers then also have
"AA=0".

-- 
	Viktor.


From paul at redbarn.org  Tue Nov 12 23:59:23 2019
From: paul at redbarn.org (Paul Vixie)
Date: Tue, 12 Nov 2019 15:59:23 -0800
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <99C36EB7-C4C6-4F78-A722-2658586E2275@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
 <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
 <4c791565-1b64-7c3e-f98b-8708aeffbf5a@redbarn.org>
 <99C36EB7-C4C6-4F78-A722-2658586E2275@dukhovni.org>
Message-ID: <da68dc61-10f9-0cd4-44f5-162d052384db@redbarn.org>



Viktor Dukhovni wrote on 2019-11-12 15:26:
>> On Nov 12, 2019, at 2:32 PM, Paul Vixie <paul at redbarn.org> wrote:
>>
>> In context, the leak I was talking about was the use of recursive data
>> in authoritative answers, coming from servers configured for both.
> 
> Can you be more explicit about what you mean by "in authoritative
> answers"?  Do you mean answers to queries with "RD=0", or answers
> with "AA=1"?

ideally, RD=0 would access only authority data, including glue for 
delegations; RD=1 would access only recursively fetched data. this calls 
for a virtual query in some delegation-point cases (like a virtual 
particle in a feinman diagram) where authoritative data is transferred 
into the recursive view exactly as if half of the server had queried the 
other half. once copied into the recursive view, its TTL would begin to 
tick down normally. RD=0 would always align with AA=1, and RD=1 would 
always align with AA=0.

> It seems that a dual-mode BIND9 server does return recursive data
> in answer to queries with "RD=0", but such answers then also have
> "AA=0".

sounds like a bug, some of which did slip through BIND9's cracks.

-- 
P Vixie


From marka at isc.org  Wed Nov 13 00:26:58 2019
From: marka at isc.org (Mark Andrews)
Date: Wed, 13 Nov 2019 11:26:58 +1100
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <99C36EB7-C4C6-4F78-A722-2658586E2275@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
 <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
 <4c791565-1b64-7c3e-f98b-8708aeffbf5a@redbarn.org>
 <99C36EB7-C4C6-4F78-A722-2658586E2275@dukhovni.org>
Message-ID: <0A7A9B2F-9F49-4C06-92E1-E23C4DEE532E@isc.org>

Named behaves as a authoritative server for RD=0 queries in
mixed mode if it is serving a enclosing zone.  Below is a recursive
query followed by a non-recursive query for the same name to the
same instance of named configured to serve the root zone.

[beetle:~/git/bind9] marka% dig -p 5333 isc.org

; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>> -p 5333 isc.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26993
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d1efb6b27cf32bc2010000005dcb4b983bb2e3dd23cf608b (good)
;; QUESTION SECTION:
;isc.org.			IN	A

;; ANSWER SECTION:
isc.org.		60	IN	A	149.20.1.66

;; Query time: 277 msec
;; SERVER: 127.0.0.1#5333(127.0.0.1)
;; WHEN: Wed Nov 13 11:17:28 AEDT 2019
;; MSG SIZE  rcvd: 80

[beetle:~/git/bind9] marka% dig -p 5333 isc.org +norec

; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>> -p 5333 isc.org +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44832
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: df9a3450addc5ae3010000005dcb4b9f7b6c9cf4990c2df0 (good)
;; QUESTION SECTION:
;isc.org.			IN	A

;; AUTHORITY SECTION:
org.			172800	IN	NS	a0.org.afilias-nst.info.
org.			172800	IN	NS	d0.org.afilias-nst.org.
org.			172800	IN	NS	b0.org.afilias-nst.org.
org.			172800	IN	NS	b2.org.afilias-nst.org.
org.			172800	IN	NS	c0.org.afilias-nst.info.
org.			172800	IN	NS	a2.org.afilias-nst.info.

;; ADDITIONAL SECTION:
d0.org.afilias-nst.org.	172800	IN	A	199.19.57.1
c0.org.afilias-nst.info. 172800	IN	A	199.19.53.1
b2.org.afilias-nst.org.	172800	IN	A	199.249.120.1
b0.org.afilias-nst.org.	172800	IN	A	199.19.54.1
a2.org.afilias-nst.info. 172800	IN	A	199.249.112.1
a0.org.afilias-nst.info. 172800	IN	A	199.19.56.1
d0.org.afilias-nst.org.	172800	IN	AAAA	2001:500:f::1
c0.org.afilias-nst.info. 172800	IN	AAAA	2001:500:b::1
b2.org.afilias-nst.org.	172800	IN	AAAA	2001:500:48::1
b0.org.afilias-nst.org.	172800	IN	AAAA	2001:500:c::1
a2.org.afilias-nst.info. 172800	IN	AAAA	2001:500:40::1
a0.org.afilias-nst.info. 172800	IN	AAAA	2001:500:e::1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5333(127.0.0.1)
;; WHEN: Wed Nov 13 11:17:35 AEDT 2019
;; MSG SIZE  rcvd: 469

[beetle:~/git/bind9] marka% cat xxx.conf
options {
	listen-on port 5333 { 127.0.0.1; };
	listen-on-v6 { none; };
};

zone "." {
	type master;
	file "root.db";
};
[beetle:~/git/bind9] marka% 


> On 13 Nov 2019, at 10:26, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
>> On Nov 12, 2019, at 2:32 PM, Paul Vixie <paul at redbarn.org> wrote:
>> 
>> In context, the leak I was talking about was the use of recursive data
>> in authoritative answers, coming from servers configured for both.
> 
> Can you be more explicit about what you mean by "in authoritative
> answers"?  Do you mean answers to queries with "RD=0", or answers
> with "AA=1"?
> 
> It seems that a dual-mode BIND9 server does return recursive data
> in answer to queries with "RD=0", but such answers then also have
> "AA=0".
> 
> -- 
> 	Viktor.
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From fw at deneb.enyo.de  Wed Nov 13 11:02:28 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 13 Nov 2019 12:02:28 +0100
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <da68dc61-10f9-0cd4-44f5-162d052384db@redbarn.org> (Paul Vixie's
 message of "Tue, 12 Nov 2019 15:59:23 -0800")
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
 <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
 <4c791565-1b64-7c3e-f98b-8708aeffbf5a@redbarn.org>
 <99C36EB7-C4C6-4F78-A722-2658586E2275@dukhovni.org>
 <da68dc61-10f9-0cd4-44f5-162d052384db@redbarn.org>
Message-ID: <877e449gzf.fsf@mid.deneb.enyo.de>

* Paul Vixie:

>> It seems that a dual-mode BIND9 server does return recursive data
>> in answer to queries with "RD=0", but such answers then also have
>> "AA=0".
>
> sounds like a bug, some of which did slip through BIND9's cracks.

Aren't there cases where BIND 9 caches data in a
supposedly-authoritative-only view because the data is needed to send
NOTIFY queries to the right addresses?

From wesley at myrambler.ru  Wed Nov 13 06:25:53 2019
From: wesley at myrambler.ru (Wesley Peng)
Date: Wed, 13 Nov 2019 14:25:53 +0800
Subject: [dns-operations] GMX tld question
Message-ID: <aa2641f4-5048-4ea0-a0b4-fd0615cb4a67@myrambler.ru>

Hello,

Is .gmx tld run by United Internet?
We have communication issue to their DNS servers.

gmx.                    21542   IN      NS      anycast10.irondns.net.
gmx.                    21542   IN      NS      anycast23.irondns.net.
gmx.                    21542   IN      NS      anycast9.irondns.net.
gmx.                    21542   IN      NS      anycast24.irondns.net.

But the communication to gmx.net NS servers gets no problem.

gmx.net.                11009   IN      NS      ns-gmx.ui-dns.com.
gmx.net.                11009   IN      NS      ns-gmx.ui-dns.biz.
gmx.net.                11009   IN      NS      ns-gmx.ui-dns.org.
gmx.net.                11009   IN      NS      ns-gmx.ui-dns.de.

If anyone know the undercase operators, please let me know.

Thank you.
regards.

From michele at blacknight.com  Wed Nov 13 14:27:11 2019
From: michele at blacknight.com (Michele Neylon - Blacknight)
Date: Wed, 13 Nov 2019 14:27:11 +0000
Subject: [dns-operations] GMX tld question
In-Reply-To: <aa2641f4-5048-4ea0-a0b4-fd0615cb4a67@myrambler.ru>
References: <aa2641f4-5048-4ea0-a0b4-fd0615cb4a67@myrambler.ru>
Message-ID: <EA919853-4828-4002-A719-CD964CE06B68@blacknight.com>

Full details here:
https://www.iana.org/domains/root/db/gmx.html


--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
https://blacknight.blog/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/ 
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845

?On 13/11/2019, 14:23, "dns-operations on behalf of Wesley Peng" <dns-operations-bounces at dns-oarc.net on behalf of wesley at myrambler.ru> wrote:

    Hello,
    
    Is .gmx tld run by United Internet?
    We have communication issue to their DNS servers.
    
    gmx.                    21542   IN      NS      anycast10.irondns.net.
    gmx.                    21542   IN      NS      anycast23.irondns.net.
    gmx.                    21542   IN      NS      anycast9.irondns.net.
    gmx.                    21542   IN      NS      anycast24.irondns.net.
    
    But the communication to gmx.net NS servers gets no problem.
    
    gmx.net.                11009   IN      NS      ns-gmx.ui-dns.com.
    gmx.net.                11009   IN      NS      ns-gmx.ui-dns.biz.
    gmx.net.                11009   IN      NS      ns-gmx.ui-dns.org.
    gmx.net.                11009   IN      NS      ns-gmx.ui-dns.de.
    
    If anyone know the undercase operators, please let me know.
    
    Thank you.
    regards.
    _______________________________________________
    dns-operations mailing list
    dns-operations at lists.dns-oarc.net
    https://lists.dns-oarc.net/mailman/listinfo/dns-operations
    



From jim at rfc1035.com  Wed Nov 13 14:40:38 2019
From: jim at rfc1035.com (Jim Reid)
Date: Wed, 13 Nov 2019 14:40:38 +0000
Subject: [dns-operations] GMX tld question
In-Reply-To: <aa2641f4-5048-4ea0-a0b4-fd0615cb4a67@myrambler.ru>
References: <aa2641f4-5048-4ea0-a0b4-fd0615cb4a67@myrambler.ru>
Message-ID: <EA4AF0E9-EB8B-4860-AA45-20E178AE1936@rfc1035.com>



> On 13 Nov 2019, at 06:25, Wesley Peng <wesley at myrambler.ru> wrote:
> 
> Is .gmx tld run by United Internet?

Knipp Medien und Kommunikation GmbH operate the DNS servers for this gTLD. 

% whois  irondns.net 
...
Registrar WHOIS Server: whois.corehub.net
Registrar URL: http://corehub.net
...
Registrar Abuse Contact Email: abuse at corehub.net
Registrar Abuse Contact Phone: +34.931807144
Reseller: CORE-39 (Knipp Medien und Kommunikation GmbH)
Domain Status: ok https://icann.org/epp#ok
...
Registrant Organization: Knipp Medien und Kommunikation GmbH
...
Registrant Email: https://corehub.net/whoiscontact/

From dot at dotat.at  Wed Nov 13 14:53:12 2019
From: dot at dotat.at (Tony Finch)
Date: Wed, 13 Nov 2019 14:53:12 +0000
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <877e449gzf.fsf@mid.deneb.enyo.de>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <C8C4953F-8672-489E-8753-46EE0454B716@isc.org>
 <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org>
 <CA+nkc8B-h9n-9=RJH3GVcG_nEGAsi2quB11Z7=HHqqWLotuunQ@mail.gmail.com>
 <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org>
 <CAKW6eLuRppUgtscOEtxUW6H+f6nxbigafAMp_T0M+_+fUH=e2g@mail.gmail.com>
 <E49CFEF8-7759-46A3-B9D9-7DF26DF5071C@dukhovni.org>
 <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org>
 <69AAEFC0-E36E-43A3-8303-2E125188795C@hopcount.ca>
 <4c791565-1b64-7c3e-f98b-8708aeffbf5a@redbarn.org>
 <99C36EB7-C4C6-4F78-A722-2658586E2275@dukhovni.org>
 <da68dc61-10f9-0cd4-44f5-162d052384db@redbarn.org>
 <877e449gzf.fsf@mid.deneb.enyo.de>
Message-ID: <alpine.DEB.2.20.1911131449390.10845@grey.csi.cam.ac.uk>

Florian Weimer <fw at deneb.enyo.de> wrote:
>
> Aren't there cases where BIND 9 caches data in a
> supposedly-authoritative-only view because the data is needed to send
> NOTIFY queries to the right addresses?

Yes, but this doesn't cause problems because you will have set
`recursion no`, which sets `allow-query-cache` to `none`.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Isle of Man: Southeast 4 or 5 imminently backing east 5 or 6 backing north or
northeast later. Slight soon becoming slight or moderate. Isolated showers,
mainly fair later. Good moderate in showers.

From ondrej at sury.org  Sun Nov 17 03:05:58 2019
From: ondrej at sury.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Sun, 17 Nov 2019 11:05:58 +0800
Subject: [dns-operations] DNS Flag Day 2020 - the date
Message-ID: <D0BA0D3D-3FE8-4712-BFAB-617AABD8D4FF@sury.org>

Hi,

I have opened a discussion issue for setting the DNS Flag Day 2020 date:

https://github.com/dns-violations/dnsflagday/issues/139

After that date the new DNS software releases will be adjusted to match
to DNS Flag Day 2020 recommendations regarding to default EDNS buffer
size and handling the TCP.

Personally, I propose to set the date to 31. October 2020, but I would like
to hear other people?s opinions.

It?s fine to discuss here, but ultimately, your opinion should be recorded
in aforementioned issue for a permanent record.

Thanks,
Ondrej
--
Ond?ej Sur?
ondrej at sury.org





From mehmet at akcin.net  Sun Nov 17 04:05:25 2019
From: mehmet at akcin.net (Mehmet Akcin)
Date: Sat, 16 Nov 2019 20:05:25 -0800
Subject: [dns-operations] DNS Flag Day 2020 - the date
In-Reply-To: <D0BA0D3D-3FE8-4712-BFAB-617AABD8D4FF@sury.org>
References: <D0BA0D3D-3FE8-4712-BFAB-617AABD8D4FF@sury.org>
Message-ID: <CA+LTh5Xz4X7_0mzrr3-uVLSpuJZZ+x-Rer-8iGAgmQUT+jw8pA@mail.gmail.com>

5/3/2020 (March)

On Sat, Nov 16, 2019 at 19:09 Ond?ej Sur? <ondrej at sury.org> wrote:

> Hi,
>
> I have opened a discussion issue for setting the DNS Flag Day 2020 date:
>
> https://github.com/dns-violations/dnsflagday/issues/139
>
> After that date the new DNS software releases will be adjusted to match
> to DNS Flag Day 2020 recommendations regarding to default EDNS buffer
> size and handling the TCP.
>
> Personally, I propose to set the date to 31. October 2020, but I would like
> to hear other people?s opinions.
>
> It?s fine to discuss here, but ultimately, your opinion should be recorded
> in aforementioned issue for a permanent record.
>
> Thanks,
> Ondrej
> --
> Ond?ej Sur?
> ondrej at sury.org
>
>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-- 
Mehmet
+1-424-298-1903
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191116/4d98b6e0/attachment.html>

From tale at dd.org  Sun Nov 17 06:30:25 2019
From: tale at dd.org (Dave Lawrence)
Date: Sun, 17 Nov 2019 01:30:25 -0500
Subject: [dns-operations] DNS Flag Day 2020 - the date
In-Reply-To: <CA+LTh5Xz4X7_0mzrr3-uVLSpuJZZ+x-Rer-8iGAgmQUT+jw8pA@mail.gmail.com>
References: <D0BA0D3D-3FE8-4712-BFAB-617AABD8D4FF@sury.org>
 <CA+LTh5Xz4X7_0mzrr3-uVLSpuJZZ+x-Rer-8iGAgmQUT+jw8pA@mail.gmail.com>
Message-ID: <24016.59649.826920.354641@gro.dd.org>

Mehmet Akcin writes:
> 5/3/2020 (March)

Because National Absinthe Day?
... National Cheese Doodle Day?
... National Multiple Personality Day?

(All true; ref: http://www.holidays-and-observances.com/march-5.html)

Or maybe it's a historical reference?  The Boston Massacre?

https://www.onthisday.com/day/march/5


If these Days of Momentous DNS Events (nee Flag Day) are an annual
thing, February 1st was the last one, right?

From chrisj at aprole.com  Sun Nov 17 21:25:57 2019
From: chrisj at aprole.com (Chris Jones)
Date: Sun, 17 Nov 2019 21:25:57 +0000
Subject: [dns-operations] DNS Flag Day 2020 - the date
In-Reply-To: <24016.59649.826920.354641@gro.dd.org>
References: <24016.59649.826920.354641@gro.dd.org>
Message-ID: <64DF369D-8263-4B43-B6BD-1C96B486369E@aprole.com>

Or because in the DD/MM/YYYY parts of the year, it encodes ?53? in the date? :)

(For the MM/DD folks, you could achieve the same thing by using May 3rd)

Regards,

Chris Jones

> On 17 Nov 2019, at 17:33, Dave Lawrence <tale at dd.org> wrote:
> 
> ?Mehmet Akcin writes:
>> 5/3/2020 (March)
> 
> Because National Absinthe Day?
> ... National Cheese Doodle Day?
> ... National Multiple Personality Day?
> 
> (All true; ref: http://www.holidays-and-observances.com/march-5.html)
> 
> Or maybe it's a historical reference?  The Boston Massacre?
> 
> https://www.onthisday.com/day/march/5
> 
> 
> If these Days of Momentous DNS Events (nee Flag Day) are an annual
> thing, February 1st was the last one, right?
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


From gregchoules at googlemail.com  Sun Nov 17 21:51:04 2019
From: gregchoules at googlemail.com (Greg Choules)
Date: Sun, 17 Nov 2019 21:51:04 +0000
Subject: [dns-operations] DNS Flag Day 2020 - the date
In-Reply-To: <64DF369D-8263-4B43-B6BD-1C96B486369E@aprole.com>
References: <24016.59649.826920.354641@gro.dd.org>
 <64DF369D-8263-4B43-B6BD-1C96B486369E@aprole.com>
Message-ID: <CANsEUy0QHJ7_2nf7imHLf7wW99JnLx7RGRRzYFxHbymdvayR0Q@mail.gmail.com>

IMHO we should all be using the ISO8601 date format.
With this in mind and sticking with the theme of encoding 53, I too would
vote for 3 May, or 2020-0*5*-0*3*.

Greg

On Sun, 17 Nov 2019 at 21:34, Chris Jones <chrisj at aprole.com> wrote:

> Or because in the DD/MM/YYYY parts of the year, it encodes ?53? in the
> date? :)
>
> (For the MM/DD folks, you could achieve the same thing by using May 3rd)
>
> Regards,
>
> Chris Jones
>
> > On 17 Nov 2019, at 17:33, Dave Lawrence <tale at dd.org> wrote:
> >
> > ?Mehmet Akcin writes:
> >> 5/3/2020 (March)
> >
> > Because National Absinthe Day?
> > ... National Cheese Doodle Day?
> > ... National Multiple Personality Day?
> >
> > (All true; ref: http://www.holidays-and-observances.com/march-5.html)
> >
> > Or maybe it's a historical reference?  The Boston Massacre?
> >
> > https://www.onthisday.com/day/march/5
> >
> >
> > If these Days of Momentous DNS Events (nee Flag Day) are an annual
> > thing, February 1st was the last one, right?
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191117/a06ffbc6/attachment.html>

From dougb at dougbarton.email  Mon Nov 18 00:21:16 2019
From: dougb at dougbarton.email (Doug Barton)
Date: Sun, 17 Nov 2019 16:21:16 -0800
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
 <24009.47145.217776.427770@gro.dd.org>
 <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
Message-ID: <93285c98-a52d-24b3-6faa-9a22d35dc0c5@dougbarton.email>

On 11/11/19 11:57 AM, Viktor Dukhovni wrote:
>> On Nov 11, 2019, at 2:36 PM, Dave Lawrence <tale at dd.org> wrote:
>>
>> In the last, AA=0 is a clear standards-noncompliant signalling failure
>> for which it is entirely appropriate to treat the responder as lame.
>> (OTOH, if the data can be DNSSEC-validated, hey then whatever, AA was
>> just redundant -- the data was authoritative even if the responder wasn't.)
> 
> But if the responder is authoritative only for a parent of the requested
> domain, and is willing to do recursion for the child zone, and has the
> answer cached, then if it also serves data from the cache with RD=0, it
> will return AA=0 for the cached data, while the requestor believes the
> server to be authoritative (for at least the top of the subtree).


I also think it's useful to define the circumstances for these various 
queries. For instance, when setting up a resolving name server for 
consulting clients I used to routinely have the resolvers slave all of 
the zones that the customer was authoritative for. That saved cycles on 
both systems, improved lookup times, etc. In that scenario the resolver 
could return AA=1 for some zones, but =0 for ones it actually had to 
recurse for. And then to make that even more exciting, it was not at all 
uncommon for companies to want a limited set of recursors that had 
access to the big, scary Internet; and a lot of local ones that 
forwarded through them for things that they weren't authoritative for. 
So every answer from the "border" resolvers would be AA=0, and every 
query from the internal ones would be RD=1.

And there are two questions I haven't seen answered here yet ... do 
resolvers always set RD=0 (and if so, why, because that makes no sense); 
and if they are supposed to set it when they query "the authoritative 
server," how do they know at what point in the chain they are at, and if 
the server they are querying is actually authoritative for the zone that 
the host they are looking for is in? Or to ask the opposite question, 
how do they tell if the AA flag is set properly?

In principle I agree with Paul that we should break things when needed, 
and break them earlier rather than later (I've been saying that for 20 
years, btw, glad to hear that folks are catching up).  :)  But it's not 
at all clear to me that this is something that has neat/clean boundaries 
around which we can justify breaking things.

Doug

From marka at isc.org  Mon Nov 18 00:50:04 2019
From: marka at isc.org (Mark Andrews)
Date: Mon, 18 Nov 2019 11:50:04 +1100
Subject: [dns-operations] sophosxl.net problem?
In-Reply-To: <93285c98-a52d-24b3-6faa-9a22d35dc0c5@dougbarton.email>
References: <EB932E33-F402-489A-8E72-EC7AE81BE99E@id.ethz.ch>
 <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net>
 <87a792wih8.fsf@oldenburg2.str.redhat.com>
 <2e2d921d-eecf-ebb1-09c5-67dec12b8bed@redbarn.org>
 <24009.47145.217776.427770@gro.dd.org>
 <7047E560-F816-42FB-AA6A-F70891963F94@dukhovni.org>
 <93285c98-a52d-24b3-6faa-9a22d35dc0c5@dougbarton.email>
Message-ID: <02D4A088-26DC-4064-B0DE-BEF4F25AD166@isc.org>



> On 18 Nov 2019, at 11:21, Doug Barton <dougb at dougbarton.email> wrote:
> 
> On 11/11/19 11:57 AM, Viktor Dukhovni wrote:
>>> On Nov 11, 2019, at 2:36 PM, Dave Lawrence <tale at dd.org> wrote:
>>> 
>>> In the last, AA=0 is a clear standards-noncompliant signalling failure
>>> for which it is entirely appropriate to treat the responder as lame.
>>> (OTOH, if the data can be DNSSEC-validated, hey then whatever, AA was
>>> just redundant -- the data was authoritative even if the responder wasn't.)
>> But if the responder is authoritative only for a parent of the requested
>> domain, and is willing to do recursion for the child zone, and has the
>> answer cached, then if it also serves data from the cache with RD=0, it
>> will return AA=0 for the cached data, while the requestor believes the
>> server to be authoritative (for at least the top of the subtree).
> 
> 
> I also think it's useful to define the circumstances for these various queries. For instance, when setting up a resolving name server for consulting clients I used to routinely have the resolvers slave all of the zones that the customer was authoritative for. That saved cycles on both systems, improved lookup times, etc. In that scenario the resolver could return AA=1 for some zones, but =0 for ones it actually had to recurse for. And then to make that even more exciting, it was not at all uncommon for companies to want a limited set of recursors that had access to the big, scary Internet; and a lot of local ones that forwarded through them for things that they weren't authoritative for. So every answer from the "border" resolvers would be AA=0, and every query from the internal ones would be RD=1.
> 
> And there are two questions I haven't seen answered here yet ... do resolvers always set RD=0 (and if so, why, because that makes no sense);

It does if you are trying to get the latest content for the zone and minimise the number of queries you make.  If you hit a misconfigured authoritative server you are getting old data.  Additionally some servers don?t follow STD 13 and return SERVFAIL for all queries for the zone if they fail to cleanly load it all.  Looking for AA=1/AA=0 allows you to reject answers from partial loads.

> and if they are supposed to set it when they query "the authoritative server," how do they know at what point in the chain they are at, and if the server they are querying is actually authoritative for the zone that the host they are looking for is in? Or to ask the opposite question, how do they tell if the AA flag is set properly?

Well a resolver should know if it is performing a iterative query (following NS records) or performing a recursive query (to specified servers).  The real problem is idiots that think that think they can redirect queries to a recursive DNS server to provide "a transparent DNS cache? and everything will just work.  It doesn?t.

> In principle I agree with Paul that we should break things when needed, and break them earlier rather than later (I've been saying that for 20 years, btw, glad to hear that folks are catching up).  :)  But it's not at all clear to me that this is something that has neat/clean boundaries around which we can justify breaking things.
> 
> Doug
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org



From geier at geier.ne.tz  Mon Nov 18 06:32:28 2019
From: geier at geier.ne.tz (Frank Habicht)
Date: Mon, 18 Nov 2019 09:32:28 +0300
Subject: [dns-operations] DNS Flag Day 2020 - the date
In-Reply-To: <64DF369D-8263-4B43-B6BD-1C96B486369E@aprole.com>
References: <24016.59649.826920.354641@gro.dd.org>
 <64DF369D-8263-4B43-B6BD-1C96B486369E@aprole.com>
Message-ID: <847799f9-2251-0a3b-adcb-ae1d7071df15@geier.ne.tz>

On 18/11/2019 00:25, Chris Jones wrote:
> Or because in the DD/MM/YYYY parts of the year, it encodes ?53? in the date? :)
> 
> (For the MM/DD folks, you could achieve the same thing by using May 3rd)
for them it's in hexadecimal - 0x35

From ietf-dane at dukhovni.org  Mon Nov 18 09:06:57 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 18 Nov 2019 04:06:57 -0500
Subject: [dns-operations] Non-EDNS FORMERR with qdcount==0?
Message-ID: <20191118090657.GY34850@straasha.imrryr.org>

EDNS(0) queries to the (protocol-violating w.r.t. to unexpected QTYPES)
nameservers for mail.protection.outlook.com, which don't support EDNS(0),
elicit a response which fails to include a copy of the original question
(see below).  Is this valid?

My response validation logic checks not only the source IP and transction id,
but also looks for a matching question, and discards the response otherwise, so
I don't see the FORMERR, and retry without EDNS(0) when the server leaves out
the question.

MUST servers reflect the question (on error?) or can they leave it out?  Is
FORMERR special in this regard (not being an answer to a question), but an
error processing my query packet?

FWIW, "unbound-host" handles the "empty" FORMERR response, and retries the
query without EDNS.  Is unbound-host doing what's expected, or employing
a work-around for known breakage?

-- 
    Viktor.

Domain Name System (query)
    Transaction ID: 0x2acf
    Flags: 0x0020 Standard query
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..1. .... = AD bit: Set
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        _25._tcp.nist-gov.mail.protection.outlook.com: type TLSA, class IN
            Name: _25._tcp.nist-gov.mail.protection.outlook.com
            [Name Length: 45]
            [Label Count: 7]
            Type: TLSA (52)
            Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (41)
            UDP payload size: 1232
            Higher bits in extended RCODE: 0x00
            EDNS0 version: 0
            Z: 0x0000
                0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
                .000 0000 0000 0000 = Reserved: 0x0000
            Data length: 0

Domain Name System (response)
    Transaction ID: 0x2acf
    Flags: 0x8001 Standard query response, Format error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0001 = Reply code: Format error (1)
    Questions: 0
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0

From muks at mukund.org  Mon Nov 18 10:24:36 2019
From: muks at mukund.org (Mukund Sivaraman)
Date: Mon, 18 Nov 2019 15:54:36 +0530
Subject: [dns-operations] Non-EDNS FORMERR with qdcount==0?
In-Reply-To: <20191118090657.GY34850@straasha.imrryr.org>
References: <20191118090657.GY34850@straasha.imrryr.org>
Message-ID: <20191118102436.GA7494@jurassic.lan.banu.com>

Hi Viktor

On Mon, Nov 18, 2019 at 04:06:57AM -0500, Viktor Dukhovni wrote:
> EDNS(0) queries to the (protocol-violating w.r.t. to unexpected QTYPES)
> nameservers for mail.protection.outlook.com, which don't support EDNS(0),
> elicit a response which fails to include a copy of the original question
> (see below).  Is this valid?
> 
> My response validation logic checks not only the source IP and transction id,
> but also looks for a matching question, and discards the response otherwise, so
> I don't see the FORMERR, and retry without EDNS(0) when the server leaves out
> the question.
> 
> MUST servers reflect the question (on error?) or can they leave it
> out?

It would depend on how much of the question was syntactically parsable.

E.g., when Loop tries to parse a client query message, it parses it in
multiple passes. In the first pass, it tries to see if the UDP
datagram/TCP "message" has enough octets for a message header. If it
doesn't, then it drops the message without any response. If it could
parse the header, it tries to parse the rest of the message. If it could
not even parse the question section in the rest of the message, it would
return a reply message with rcode=FORMERR without a question section in
the reply.

> Is FORMERR special in this regard (not being an answer to a question),
> but an error processing my query packet?

Maybe the outlook.com implementation thinks this question is
syntactically incorrect, and so it can't use it in the reply.

> FWIW, "unbound-host" handles the "empty" FORMERR response, and retries the
> query without EDNS.  Is unbound-host doing what's expected, or employing
> a work-around for known breakage?

Loop's resolver does the same too, and appears to be a workaround (the
code is from 2000 by Bob Halley written for BIND, and it describes the
same). If EDNS is not used in the query and this happens, it abandons
the query completely without trying any other nameservers because it
expects all of them would have trouble with some aspect of this query.

		Mukund

From marka at isc.org  Mon Nov 18 10:35:34 2019
From: marka at isc.org (Mark Andrews)
Date: Mon, 18 Nov 2019 21:35:34 +1100
Subject: [dns-operations] Non-EDNS FORMERR with qdcount==0?
In-Reply-To: <20191118090657.GY34850@straasha.imrryr.org>
References: <20191118090657.GY34850@straasha.imrryr.org>
Message-ID: <2991810A-BCB1-4134-95F7-C9795513784A@isc.org>

FORMERR without a question section is valid.  What happens when you can?t
decode the question section?  If the question section is there and it is
a QUERY they the question should match.

> On 18 Nov 2019, at 20:06, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> EDNS(0) queries to the (protocol-violating w.r.t. to unexpected QTYPES)
> nameservers for mail.protection.outlook.com, which don't support EDNS(0),
> elicit a response which fails to include a copy of the original question
> (see below).  Is this valid?
> 
> My response validation logic checks not only the source IP and transction id,
> but also looks for a matching question, and discards the response otherwise, so
> I don't see the FORMERR, and retry without EDNS(0) when the server leaves out
> the question.
> 
> MUST servers reflect the question (on error?) or can they leave it out?  Is
> FORMERR special in this regard (not being an answer to a question), but an
> error processing my query packet?
> 
> FWIW, "unbound-host" handles the "empty" FORMERR response, and retries the
> query without EDNS.  Is unbound-host doing what's expected, or employing
> a work-around for known breakage?
> 
> -- 
>    Viktor.
> 
> Domain Name System (query)
>    Transaction ID: 0x2acf
>    Flags: 0x0020 Standard query
>        0... .... .... .... = Response: Message is a query
>        .000 0... .... .... = Opcode: Standard query (0)
>        .... ..0. .... .... = Truncated: Message is not truncated
>        .... ...0 .... .... = Recursion desired: Don't do query recursively
>        .... .... .0.. .... = Z: reserved (0)
>        .... .... ..1. .... = AD bit: Set
>        .... .... ...0 .... = Non-authenticated data: Unacceptable
>    Questions: 1
>    Answer RRs: 0
>    Authority RRs: 0
>    Additional RRs: 1
>    Queries
>        _25._tcp.nist-gov.mail.protection.outlook.com: type TLSA, class IN
>            Name: _25._tcp.nist-gov.mail.protection.outlook.com
>            [Name Length: 45]
>            [Label Count: 7]
>            Type: TLSA (52)
>            Class: IN (0x0001)
>    Additional records
>        <Root>: type OPT
>            Name: <Root>
>            Type: OPT (41)
>            UDP payload size: 1232
>            Higher bits in extended RCODE: 0x00
>            EDNS0 version: 0
>            Z: 0x0000
>                0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
>                .000 0000 0000 0000 = Reserved: 0x0000
>            Data length: 0
> 
> Domain Name System (response)
>    Transaction ID: 0x2acf
>    Flags: 0x8001 Standard query response, Format error
>        1... .... .... .... = Response: Message is a response
>        .000 0... .... .... = Opcode: Standard query (0)
>        .... .0.. .... .... = Authoritative: Server is not an authority for domain
>        .... ..0. .... .... = Truncated: Message is not truncated
>        .... ...0 .... .... = Recursion desired: Don't do query recursively
>        .... .... 0... .... = Recursion available: Server can't do recursive queries
>        .... .... .0.. .... = Z: reserved (0)
>        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
>        .... .... ...0 .... = Non-authenticated data: Unacceptable
>        .... .... .... 0001 = Reply code: Format error (1)
>    Questions: 0
>    Answer RRs: 0
>    Authority RRs: 0
>    Additional RRs: 0
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org



From ietf-dane at dukhovni.org  Mon Nov 18 10:42:27 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 18 Nov 2019 05:42:27 -0500
Subject: [dns-operations] Non-EDNS FORMERR with qdcount==0?
In-Reply-To: <20191118102436.GA7494@jurassic.lan.banu.com>
References: <20191118090657.GY34850@straasha.imrryr.org>
 <20191118102436.GA7494@jurassic.lan.banu.com>
Message-ID: <20191118104227.GZ34850@straasha.imrryr.org>

On Mon, Nov 18, 2019 at 03:54:36PM +0530, Mukund Sivaraman wrote:

> > MUST servers reflect the question (on error?) or can they leave it
> > out?
> 
> It would depend on how much of the question was syntactically parsable.

My example queries had a well-formed question, along with an EDNS(0)
OPT record, but the FORMERR response had an empty question section.
So, whether that's valid or not, I guess I'll have to accept that
as a matching response that indicates lack of EDNS(0) support, and
retry without EDNS.

> > Is FORMERR special in this regard (not being an answer to a question),
> > but an error processing my query packet?
> 
> Maybe the outlook.com implementation thinks this question is
> syntactically incorrect, and so it can't use it in the reply.

It groks the same question once the OPT record is left out.

> > FWIW, "unbound-host" handles the "empty" FORMERR response, and retries the
> > query without EDNS.  Is unbound-host doing what's expected, or employing
> > a work-around for known breakage?
> 
> Loop's resolver does the same too, and appears to be a workaround (the
> code is from 2000 by Bob Halley written for BIND, and it describes the
> same).

I pushed a bugfix:

    https://github.com/kazu-yamamoto/dns/commit/de1063e4cfcbc582074dd911e637053876886670

    +-- When the response 'RCODE' is 'FormatErr', the server did not understand our
    +-- query packet, and so is not expected to return a matching question.
    +--
     checkRespM :: Question -> Identifier -> DNSMessage -> Maybe DNSError
     checkRespM q seqno resp
       | identifier (header resp) /= seqno = Just SequenceNumberMismatch
    +  | FormatErr <- rcode $ flags $ header resp
    +  , []        <- question resp        = Nothing
       | [q] /= question resp              = Just QuestionMismatch
       | otherwise                         = Nothing

-- 
    Viktor.

From ietf-dane at dukhovni.org  Mon Nov 18 10:42:27 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 18 Nov 2019 05:42:27 -0500
Subject: [dns-operations] Non-EDNS FORMERR with qdcount==0?
In-Reply-To: <20191118102436.GA7494@jurassic.lan.banu.com>
References: <20191118090657.GY34850@straasha.imrryr.org>
 <20191118102436.GA7494@jurassic.lan.banu.com>
Message-ID: <20191118104227.GZ34850@straasha.imrryr.org>

On Mon, Nov 18, 2019 at 03:54:36PM +0530, Mukund Sivaraman wrote:

> > MUST servers reflect the question (on error?) or can they leave it
> > out?
> 
> It would depend on how much of the question was syntactically parsable.

My example queries had a well-formed question, along with an EDNS(0)
OPT record, but the FORMERR response had an empty question section.
So, whether that's valid or not, I guess I'll have to accept that
as a matching response that indicates lack of EDNS(0) support, and
retry without EDNS.

> > Is FORMERR special in this regard (not being an answer to a question),
> > but an error processing my query packet?
> 
> Maybe the outlook.com implementation thinks this question is
> syntactically incorrect, and so it can't use it in the reply.

It groks the same question once the OPT record is left out.

> > FWIW, "unbound-host" handles the "empty" FORMERR response, and retries the
> > query without EDNS.  Is unbound-host doing what's expected, or employing
> > a work-around for known breakage?
> 
> Loop's resolver does the same too, and appears to be a workaround (the
> code is from 2000 by Bob Halley written for BIND, and it describes the
> same).

I pushed a bugfix:

    https://github.com/kazu-yamamoto/dns/commit/de1063e4cfcbc582074dd911e637053876886670

    +-- When the response 'RCODE' is 'FormatErr', the server did not understand our
    +-- query packet, and so is not expected to return a matching question.
    +--
     checkRespM :: Question -> Identifier -> DNSMessage -> Maybe DNSError
     checkRespM q seqno resp
       | identifier (header resp) /= seqno = Just SequenceNumberMismatch
    +  | FormatErr <- rcode $ flags $ header resp
    +  , []        <- question resp        = Nothing
       | [q] /= question resp              = Just QuestionMismatch
       | otherwise                         = Nothing

-- 
    Viktor.

From miesi at mail.com  Mon Nov 18 09:08:35 2019
From: miesi at mail.com (Thomas Mieslinger)
Date: Mon, 18 Nov 2019 10:08:35 +0100
Subject: [dns-operations] .cm DNS setup
Message-ID: <82bffb8d-aa83-d5ac-e5b5-e62a38a39f1e@mail.com>

Hi,

I have a customer complaining that his mail to camccul.cm do bounce.

After checking my recursive and authoritative DNS, I took a look on .cm
setup:

.cm has the following nameservers configured in root zone:
cm. 172800 IN NS sanaga.camnet.cm.
cm. 172800 IN NS ns.itu.ch.
cm. 172800 IN NS kim.camnet.cm.
cm. 172800 IN NS lom.camnet.cm.
cm. 172800 IN NS auth02.ns.uu.net.

auth02.ns.uu.net. returns SERVFAIL for dig camccul.cm @auth02.ns.uu.net
sanaga.camnet.cm. times out

.cm has the following nameservers configured in .cm zone
cm. 86400 IN NS mbam.camnet.cm.
cm. 86400 IN NS ns-cm.afrinic.net.
cm. 86400 IN NS auth02.ns.uu.net.
cm. 86400 IN NS ns2.nic.cm.
cm. 86400 IN NS benoue.camnet.cm.
cm. 86400 IN NS phloem.uoregon.edu.
cm. 86400 IN NS ns1.nic.cm.
cm. 86400 IN NS ns.itu.ch.
cm. 86400 IN NS ns-cm.nic.fr.
cm. 86400 IN NS lom.camnet.cm.
cm. 86400 IN NS kim.camnet.cm.

auth02.ns.uu.net. returns SERVFAIL for dig camccul.cm @auth02.ns.uu.net
benoue.camnet.cm does not exist

.cm, would you please take a look?

Thanks

Thomas Mieslinger

P.S.: please also fix mail setup for dotcm at antic.cm (SOA mail field)


From Jacques.Latour at cira.ca  Mon Nov 18 21:34:22 2019
From: Jacques.Latour at cira.ca (Jacques Latour)
Date: Mon, 18 Nov 2019 21:34:22 +0000
Subject: [dns-operations] [EXT]  .cm DNS setup
In-Reply-To: <82bffb8d-aa83-d5ac-e5b5-e62a38a39f1e@mail.com>
References: <82bffb8d-aa83-d5ac-e5b5-e62a38a39f1e@mail.com>
Message-ID: <b1057dea015449e3a652a264a93ebcc4@cira.ca>

Forwarded to TLD-OPS. 

>-----Original Message-----
>From: dns-operations <dns-operations-bounces at dns-oarc.net> On Behalf Of Thomas Mieslinger
>Sent: November 18, 2019 4:09 AM
>To: dns-operations at dns-oarc.net
>Subject: [EXT] [dns-operations] .cm DNS setup
>
>Hi,
>
>I have a customer complaining that his mail to camccul.cm do bounce.
>
>After checking my recursive and authoritative DNS, I took a look on .cm
>setup:
>
>.cm has the following nameservers configured in root zone:
>cm. 172800 IN NS sanaga.camnet.cm.
>cm. 172800 IN NS ns.itu.ch.
>cm. 172800 IN NS kim.camnet.cm.
>cm. 172800 IN NS lom.camnet.cm.
>cm. 172800 IN NS auth02.ns.uu.net.
>
>auth02.ns.uu.net. returns SERVFAIL for dig camccul.cm @auth02.ns.uu.net
>sanaga.camnet.cm. times out
>
>.cm has the following nameservers configured in .cm zone
>cm. 86400 IN NS mbam.camnet.cm.
>cm. 86400 IN NS ns-cm.afrinic.net.
>cm. 86400 IN NS auth02.ns.uu.net.
>cm. 86400 IN NS ns2.nic.cm.
>cm. 86400 IN NS benoue.camnet.cm.
>cm. 86400 IN NS phloem.uoregon.edu.
>cm. 86400 IN NS ns1.nic.cm.
>cm. 86400 IN NS ns.itu.ch.
>cm. 86400 IN NS ns-cm.nic.fr.
>cm. 86400 IN NS lom.camnet.cm.
>cm. 86400 IN NS kim.camnet.cm.
>
>auth02.ns.uu.net. returns SERVFAIL for dig camccul.cm @auth02.ns.uu.net
>benoue.camnet.cm does not exist
>
>.cm, would you please take a look?
>
>Thanks
>
>Thomas Mieslinger
>
>P.S.: please also fix mail setup for dotcm at antic.cm (SOA mail field)
>
>_______________________________________________
>dns-operations mailing list
>dns-operations at lists.dns-oarc.net
>https://lists.dns-oarc.net/mailman/listinfo/dns-operations