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


From ietf-dane at dukhovni.org  Sun Nov 24 07:17:10 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 24 Nov 2019 02:17:10 -0500
Subject: [dns-operations] Incomplete NSEC3 denial of existence from
 domaincontrol.com servers
Message-ID: <20191124071710.GY34850@straasha.imrryr.org>

The NSEC3 denial of existence for the TLSA records of at least 202 MX hosts (in
178 domains) is bogus, because the QNAME (or sometimes the wildcard if the
qname is covered "by accident") is not covered by any NSEC3 RR.  In the below
example (RRSIGs elided), the sole NSEC3 RR only covers the zone apex:

    @pdns05.domaincontrol.com.[97.74.110.52]
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55506
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_25._tcp.nightlifeinbangkok.com. IN TLSA
    nightlifeinbangkok.com. SOA     pdns05.domaincontrol.com. dns.jomax.net. 2019110901 28800 7200 604800 600
    kd5lt0sl1v8e2r1eoib3alo9iu417871.nightlifeinbangkok.com. NSEC3 1 0 1 - KR3PBJU1KUHPUCPBBVANN5QJKTE3ARN0 A NS SOA TXT RRSIG DNSKEY NSEC3PARAM CDS CDNSKEY

    @pdns06.domaincontrol.com.[173.201.78.52]
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59032
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_25._tcp.nightlifeinbangkok.com. IN TLSA
    nightlifeinbangkok.com. SOA     pdns05.domaincontrol.com. dns.jomax.net. 2019110901 28800 7200 604800 600
    kd5lt0sl1v8e2r1eoib3alo9iu417871.nightlifeinbangkok.com. NSEC3 1 0 1 - KR3PBJU1KUHPUCPBBVANN5QJKTE3ARN0 A NS SOA TXT RRSIG DNSKEY NSEC3PARAM CDS CDNSKEY

    Relevant hashes:
    9km4c75r7bndmh1l33fucm7sdsqj6jef. _25._tcp.nightlifeinbangkok.com
    9mlqhb5pmr7f1o7goeqk04dl1ijqttlo. *._tcp.nightlifeinbangkok.com
    ak4novl0963d2t45t9olk5g5duimgb79. _tcp.nightlifeinbangkok.com
    sm7p33mq969iuo1d3fq454je1ofjh2v4. *.nightlifeinbangkok.com
    kd5lt0sl1v8e2r1eoib3alo9iu417871. nightlifeinbangkok.com

All 202 TLSA qnames with DNSViz graphs at:

    https://imrryr.org/~viktor/dnsviz/domaincontrol.com.html

The mname frequencies from the SOA RR are:

    21 pdns01.domaincontrol.com.
    25 pdns03.domaincontrol.com.
    39 pdns05.domaincontrol.com.
    36 pdns07.domaincontrol.com.
    14 pdns09.domaincontrol.com.
    48 pdns11.domaincontrol.com.
    19 pdns13.domaincontrol.com.

-- 
    Viktor.

From postmaster at wsly.de  Mon Nov 25 12:57:16 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Mon, 25 Nov 2019 20:57:16 +0800
Subject: [dns-operations] Questions about my domain's DNS
Message-ID: <5784851a-f9c6-d2eb-2e8c-90a75869d46b@wsly.de>

Hallo,

I am confused about my domain's DNS glues. The domain is: wsly.de

When I queried to .de's root nameservers, I got:

$ dig wsly.de @n.de.net

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> wsly.de @n.de.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58894
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wsly.de.                       IN      A

;; AUTHORITY SECTION:
wsly.de.                86400   IN      NS      ns1.alldomains.hosting.
wsly.de.                86400   IN      NS      ns2.alldomains.hosting.
wsly.de.                86400   IN      NS      ns3.alldomains.hosting.
wsly.de.                86400   IN      NS      ns4.alldomains.hosting.


Then I queried to one of the above nameservers, I got:

$ dig wsly.de @ns1.alldomains.hosting

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> wsly.de @ns1.alldomains.hosting
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47694
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wsly.de.                       IN      A

;; ANSWER SECTION:
wsly.de.                86400   IN      A       213.145.224.20

;; AUTHORITY SECTION:
wsly.de.                86400   IN      NS      art.ns.cloudflare.com.
wsly.de.                86400   IN      NS      roxy.ns.cloudflare.com.



I was confused, since I have changed the domain's nameservers to 
cloudflare's, why .de's root servers still give the clues that I am 
using ns[1-4].alldomains.hosting?

And under this way, cloudflare's nameservers don't have the chance to 
resolve my domain. Am I right?

Thank you.
Regards.


From elmi at 4ever.de  Mon Nov 25 13:56:51 2019
From: elmi at 4ever.de (Elmar K. Bins)
Date: Mon, 25 Nov 2019 14:56:51 +0100
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <5784851a-f9c6-d2eb-2e8c-90a75869d46b@wsly.de>
References: <5784851a-f9c6-d2eb-2e8c-90a75869d46b@wsly.de>
Message-ID: <20191125135651.zptxv2apqbheroi4@ekbbook.local>

Hi Wesley,

postmaster at wsly.de (Wesley Peng) wrote:

> ;; AUTHORITY SECTION:
> wsly.de.                86400   IN      NS      ns1.alldomains.hosting.
> wsly.de.                86400   IN      NS      ns2.alldomains.hosting.
> wsly.de.                86400   IN      NS      ns3.alldomains.hosting.
> wsly.de.                86400   IN      NS      ns4.alldomains.hosting.

> ;; AUTHORITY SECTION:
> wsly.de.                86400   IN      NS      art.ns.cloudflare.com.
> wsly.de.                86400   IN      NS      roxy.ns.cloudflare.com.

> I was confused, since I have changed the domain's nameservers to
> cloudflare's, why .de's root servers still give the clues that I am using
> ns[1-4].alldomains.hosting?

In order to update the records in "de" you need your domain provider to send
them an update of the nameservers.

- Elmar.

From ietf-dane at dukhovni.org  Mon Nov 25 14:10:13 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 25 Nov 2019 09:10:13 -0500
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <20191125135651.zptxv2apqbheroi4@ekbbook.local>
References: <5784851a-f9c6-d2eb-2e8c-90a75869d46b@wsly.de>
 <20191125135651.zptxv2apqbheroi4@ekbbook.local>
Message-ID: <20191125141013.GB34850@straasha.imrryr.org>

On Mon, Nov 25, 2019 at 02:56:51PM +0100, Elmar K. Bins wrote:

> > ;; AUTHORITY SECTION:
> > wsly.de.                86400   IN      NS      art.ns.cloudflare.com.
> > wsly.de.                86400   IN      NS      roxy.ns.cloudflare.com.
> 
> In order to update the records in "de" you need your domain provider to send
> them an update of the nameservers.

More precisely, the registrar rather than the DNS operator when these
are different.  But in this case no need, the .de glue has already been
updated:

    wsly.de. IN NS art.ns.cloudflare.com.
    wsly.de. IN NS roxy.ns.cloudflare.com.

and WHOIS reports:

    Domain: wsly.de
    Nserver: art.ns.cloudflare.com
    Nserver: roxy.ns.cloudflare.com
    Changed: 2019-11-25T13:20:29+01:00

-- 
    Viktor.

From postmaster at wsly.de  Mon Nov 25 14:20:17 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Mon, 25 Nov 2019 22:20:17 +0800
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <20191125135651.zptxv2apqbheroi4@ekbbook.local>
Message-ID: <154dd766-b6fe-410d-bbd1-50b6959a9995@pengyonghuade-iPhone>

      
  

 Hello
  

  
When I changed name servers in registrar, won?t they be registered into DE?s servers automatically? Thank you.
  

  
  

  
  
>   
> On Nov 25, 2019 at 9:56 PM,  <Elmar K. Bins (mailto:elmi at 4ever.de)>  wrote:
>   
>   
>   
>  Hi Wesley,  
>
> postmaster at wsly.de (Wesley Peng) wrote:  
>
> >  ;; AUTHORITY SECTION:  
> >  wsly.de. 86400 IN NS ns1.alldomains.hosting.  
> >  wsly.de. 86400 IN NS ns2.alldomains.hosting.  
> >  wsly.de. 86400 IN NS ns3.alldomains.hosting.  
> >  wsly.de. 86400 IN NS ns4.alldomains.hosting.  
>
> >  ;; AUTHORITY SECTION:  
> >  wsly.de. 86400 IN NS art.ns.cloudflare.com.  
> >  wsly.de. 86400 IN NS roxy.ns.cloudflare.com.  
>
> >  I was confused, since I have changed the domain's nameservers to  
> >  cloudflare's, why .de's root servers still give the clues that I am using  
> >  ns[1-4].alldomains.hosting?  
>
> In order to update the records in "de" you need your domain provider to send  
> them an update of the nameservers.  
>
> - Elmar.  
>              
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191125/f5115d41/attachment.html>

From michele at blacknight.com  Mon Nov 25 14:22:56 2019
From: michele at blacknight.com (Michele Neylon - Blacknight)
Date: Mon, 25 Nov 2019 14:22:56 +0000
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <154dd766-b6fe-410d-bbd1-50b6959a9995@pengyonghuade-iPhone>
References: <20191125135651.zptxv2apqbheroi4@ekbbook.local>
 <154dd766-b6fe-410d-bbd1-50b6959a9995@pengyonghuade-iPhone>
Message-ID: <46052EB8-0468-45C2-81BC-5AF34EC125DF@blacknight.com>

That depends on how they?re integrated
It?s really a question you need to be asking them


--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
http://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


From: dns-operations <dns-operations-bounces at dns-oarc.net> on behalf of Wesley Peng <postmaster at wsly.de>
Date: Monday 25 November 2019 at 15:22
To: "Elmar K. Bins" <elmi at 4ever.de>
Cc: Dns-Operations <dns-operations at lists.dns-oarc.net>
Subject: Re: [dns-operations] Questions about my domain's DNS

Hello

When I changed name servers in registrar, won?t they be registered into DE?s servers automatically? Thank you.



On Nov 25, 2019 at 9:56 PM, <Elmar K. Bins<mailto:elmi at 4ever.de>> wrote:

Hi Wesley,



postmaster at wsly.de (Wesley Peng) wrote:



> ;; AUTHORITY SECTION:

> wsly.de.                86400   IN      NS      ns1.alldomains.hosting.

> wsly.de.                86400   IN      NS      ns2.alldomains.hosting.

> wsly.de.                86400   IN      NS      ns3.alldomains.hosting.

> wsly.de.                86400   IN      NS      ns4.alldomains.hosting.



> ;; AUTHORITY SECTION:

> wsly.de.                86400   IN      NS      art.ns.cloudflare.com.

> wsly.de.                86400   IN      NS      roxy.ns.cloudflare.com.



> I was confused, since I have changed the domain's nameservers to

> cloudflare's, why .de's root servers still give the clues that I am using

> ns[1-4].alldomains.hosting?



In order to update the records in "de" you need your domain provider to send

them an update of the nameservers.



- Elmar.


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

From pk at denic.de  Mon Nov 25 14:38:22 2019
From: pk at denic.de (Peter Koch)
Date: Mon, 25 Nov 2019 15:38:22 +0100
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <154dd766-b6fe-410d-bbd1-50b6959a9995@pengyonghuade-iPhone>
References: <20191125135651.zptxv2apqbheroi4@ekbbook.local>
 <154dd766-b6fe-410d-bbd1-50b6959a9995@pengyonghuade-iPhone>
Message-ID: <20191125143822.GK57997@x11672.adm.denic.de>

On Mon, Nov 25, 2019 at 10:20:17PM +0800, Wesley Peng wrote:

> When I changed name servers in registrar, won?t they be registered into DE?s servers automatically? Thank you.

without knowing details about the registrar/reseller chain that you might be
using, informing the registrar of such a change is a prerequisite for the
delegation to change at the TLD level.  That means, the registrar will
change the respective entries in the TLD registry.  In the case of DE,
the current (sic!) cadence of zone publication is once per hour, which makes you
incur a delay of up to two ours in the worst case.  Meanwhile, your changes
have made it into the DE zone (as published trough the DE TLD nameservers).

-Peter

From postmaster at wsly.de  Mon Nov 25 14:38:32 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Mon, 25 Nov 2019 22:38:32 +0800
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <46052EB8-0468-45C2-81BC-5AF34EC125DF@blacknight.com>
Message-ID: <46645986-c805-435e-bc66-116e53ce9852@pengyonghuade-iPhone>

      
  

 I saw blacknight does good business on domain industry. How do you handle DNS delegation like my case? Thanks.
  

  
  

  
  
>   
> On Nov 25, 2019 at 10:22 PM,  <Michele Neylon - Blacknight (mailto:michele at blacknight.com)>  wrote:
>   
>   
>       
>   
>
> That depends on how they?re integrated
>
>   
>
> It?s really a question you need to be asking them
>
>   
>
>   
>
>   
>
>   
>
>   
>   
>
> --
>
>   
>
> Mr Michele Neylon
>
>   
>
> Blacknight Solutions
>
>   
>
> Hosting, Colocation  &  Domains
>
>   
>
> https://www.blacknight.com/
>
>   
>
> http://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
>
>   
>   
>
>   
>
>   
>
>   
>
>   
>   
>
> From:   dns-operations  <dns-operations-bounces at dns-oarc.net>  on behalf of Wesley Peng  <postmaster at wsly.de>
>   Date:  Monday 25 November 2019 at 15:22
>   To:  "Elmar K. Bins"  <elmi at 4ever.de>
>   Cc:  Dns-Operations  <dns-operations at lists.dns-oarc.net>
>   Subject:  Re: [dns-operations] Questions about my domain's DNS
>
>   
>   
>   
>
>   
>
>   
>   
>   
>
> Hello
>
>   
>   
>   
>
>   
>
>   
>   
>   
>
> When I changed name servers in registrar, won?t they be registered into DE?s servers automatically? Thank you.
>
>   
>   
>   
>   
>
>
>   
>   
>
>
>   
> >   
> >   
> >
> > On Nov 25, 2019 at 9:56 PM,  <Elmar K. Bins (mailto:elmi at 4ever.de)>  wrote:
> >
> >   
> >   
> >   
> >  Hi Wesley,  
> >   
> >   
> >
> >     
> >   
> > postmaster at wsly.de (Wesley Peng) wrote:    
> >   
> >
> >     
> >   
> > >  ;; AUTHORITY SECTION:    
> >   
> > >  wsly.de. 86400 IN NS ns1.alldomains.hosting.    
> >   
> > >  wsly.de. 86400 IN NS ns2.alldomains.hosting.    
> >   
> > >  wsly.de. 86400 IN NS ns3.alldomains.hosting.    
> >   
> > >  wsly.de. 86400 IN NS ns4.alldomains.hosting.    
> >   
> >
> >     
> >   
> > >  ;; AUTHORITY SECTION:    
> >   
> > >  wsly.de. 86400 IN NS art.ns.cloudflare.com.    
> >   
> > >  wsly.de. 86400 IN NS roxy.ns.cloudflare.com.    
> >   
> >
> >     
> >   
> > >  I was confused, since I have changed the domain's nameservers to    
> >   
> > >  cloudflare's, why .de's root servers still give the clues that I am using    
> >   
> > >  ns[1-4].alldomains.hosting?    
> >   
> >
> >     
> >   
> > In order to update the records in "de" you need your domain provider to send    
> >   
> > them an update of the nameservers.    
> >   
> >
> >     
> >   
> > - Elmar.    
> >   
> >
> >   
>   
>   
>   
>   
>   
  
  
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191125/db16890d/attachment.html>

From michele at blacknight.com  Mon Nov 25 14:52:36 2019
From: michele at blacknight.com (Michele Neylon - Blacknight)
Date: Mon, 25 Nov 2019 14:52:36 +0000
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <46645986-c805-435e-bc66-116e53ce9852@pengyonghuade-iPhone>
References: <46052EB8-0468-45C2-81BC-5AF34EC125DF@blacknight.com>
 <46645986-c805-435e-bc66-116e53ce9852@pengyonghuade-iPhone>
Message-ID: <5B847AA9-2C8A-4B44-8056-4327F9F6EA64@blacknight.com>

If we are directly integrated with the registry then a nameserver change is almost instant.
But we aren?t directly integrated with all registries and not all of them handle DNS changes in the same way
Some, for example, will do a pre-check before they?ll allow a change.


--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
http://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


From: dns-operations <dns-operations-bounces at dns-oarc.net> on behalf of Wesley Peng <postmaster at wsly.de>
Date: Monday 25 November 2019 at 15:45
To: Dns-Operations <dns-operations at lists.dns-oarc.net>
Subject: Re: [dns-operations] Questions about my domain's DNS

I saw blacknight does good business on domain industry. How do you handle DNS delegation like my case? Thanks.



On Nov 25, 2019 at 10:22 PM, <Michele Neylon - Blacknight<mailto:michele at blacknight.com>> wrote:
That depends on how they?re integrated
It?s really a question you need to be asking them


--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
http://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


From: dns-operations <dns-operations-bounces at dns-oarc.net> on behalf of Wesley Peng <postmaster at wsly.de>
Date: Monday 25 November 2019 at 15:22
To: "Elmar K. Bins" <elmi at 4ever.de>
Cc: Dns-Operations <dns-operations at lists.dns-oarc.net>
Subject: Re: [dns-operations] Questions about my domain's DNS

Hello

When I changed name servers in registrar, won?t they be registered into DE?s servers automatically? Thank you.




On Nov 25, 2019 at 9:56 PM, <Elmar K. Bins<mailto:elmi at 4ever.de>> wrote:

Hi Wesley,




postmaster at wsly.de (Wesley Peng) wrote:




> ;; AUTHORITY SECTION:

> wsly.de.                86400   IN      NS      ns1.alldomains.hosting.

> wsly.de.                86400   IN      NS      ns2.alldomains.hosting.

> wsly.de.                86400   IN      NS      ns3.alldomains.hosting.

> wsly.de.                86400   IN      NS      ns4.alldomains.hosting.




> ;; AUTHORITY SECTION:

> wsly.de.                86400   IN      NS      art.ns.cloudflare.com.

> wsly.de.                86400   IN      NS      roxy.ns.cloudflare.com.




> I was confused, since I have changed the domain's nameservers to

> cloudflare's, why .de's root servers still give the clues that I am using

> ns[1-4].alldomains.hosting?




In order to update the records in "de" you need your domain provider to send

them an update of the nameservers.




- Elmar.


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

From postmaster at wsly.de  Mon Nov 25 14:55:09 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Mon, 25 Nov 2019 22:55:09 +0800
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <5B847AA9-2C8A-4B44-8056-4327F9F6EA64@blacknight.com>
Message-ID: <4ea5f73d-c5d5-47e2-a57b-bd58c5b2bf47@pengyonghuade-iPhone>

      
  

 Got it, thanks.
  

  
Regards   
  

  
  

  
  
>   
> On Nov 25, 2019 at 10:52 PM,  <Michele Neylon - Blacknight (mailto:michele at blacknight.com)>  wrote:
>   
>   
>       
>   
>
> If we are directly integrated with the registry then a nameserver change is almost instant.
>
>   
>
> But we aren?t directly integrated with all registries and not all of them handle DNS changes in the same way
>
>   
>
> Some, for example, will do a pre-check before they?ll allow a change.
>
>   
>
>   
>
>   
>
>   
>
>   
>   
>
> --
>
>   
>
> Mr Michele Neylon
>
>   
>
> Blacknight Solutions
>
>   
>
> Hosting, Colocation  &  Domains
>
>   
>
> https://www.blacknight.com/
>
>   
>
> http://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
>
>   
>   
>
>   
>
>   
>
>   
>
>   
>   
>
> From:   dns-operations  <dns-operations-bounces at dns-oarc.net>  on behalf of Wesley Peng  <postmaster at wsly.de>
>   Date:  Monday 25 November 2019 at 15:45
>   To:  Dns-Operations  <dns-operations at lists.dns-oarc.net>
>   Subject:  Re: [dns-operations] Questions about my domain's DNS
>
>   
>   
>   
>
>   
>
>   
>   
>   
>
> I saw blacknight does good business on domain industry. How do you handle DNS delegation like my case? Thanks.
>
>   
>   
>   
>   
>
>
>   
>   
>
>
>   
> >   
> >   
> >
> > On Nov 25, 2019 at 10:22 PM,  <Michele Neylon - Blacknight (mailto:michele at blacknight.com)>  wrote:
> >
> >   
> >   
> >   
> >
> > That depends on how they?re integrated
> >
> >   
> >
> > It?s really a question you need to be asking them
> >
> >   
> >
> >   
> >
> >   
> >
> >   
> >
> >   
> >   
> >
> > --
> >
> >   
> >
> > Mr Michele Neylon
> >
> >   
> >
> > Blacknight Solutions
> >
> >   
> >
> > Hosting, Colocation  &  Domains
> >
> >   
> >
> > https://www.blacknight.com/
> >
> >   
> >
> > http://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
> >
> >   
> >   
> >
> >   
> >
> >   
> >
> >   
> >
> >   
> >   
> >
> > From:   dns-operations  <dns-operations-bounces at dns-oarc.net>  on behalf of Wesley Peng  <postmaster at wsly.de>
> >   Date:  Monday 25 November 2019 at 15:22
> >   To:  "Elmar K. Bins"  <elmi at 4ever.de>
> >   Cc:  Dns-Operations  <dns-operations at lists.dns-oarc.net>
> >   Subject:  Re: [dns-operations] Questions about my domain's DNS
> >
> >   
> >   
> >   
> >
> >   
> >
> >   
> >   
> >   
> >
> > Hello
> >
> >   
> >   
> >   
> >
> >   
> >
> >   
> >   
> >   
> >
> > When I changed name servers in registrar, won?t they be registered into DE?s servers automatically? Thank you.
> >
> >   
> >   
> >   
> >   
> >
> >
> >   
> >   
> >   
> >
> >
> >   
> > >   
> > >   
> > >
> > > On Nov 25, 2019 at 9:56 PM,  <Elmar K. Bins (mailto:elmi at 4ever.de)>  wrote:
> > >
> > >   
> > >   
> > >   
> > >  Hi Wesley,  
> > >   
> > >   
> > >
> > >
> > >     
> > >   
> > > postmaster at wsly.de (Wesley Peng) wrote:    
> > >   
> > >
> > >
> > >     
> > >   
> > > >  ;; AUTHORITY SECTION:    
> > >   
> > > >  wsly.de. 86400 IN NS ns1.alldomains.hosting.    
> > >   
> > > >  wsly.de. 86400 IN NS ns2.alldomains.hosting.    
> > >   
> > > >  wsly.de. 86400 IN NS ns3.alldomains.hosting.    
> > >   
> > > >  wsly.de. 86400 IN NS ns4.alldomains.hosting.    
> > >   
> > >
> > >
> > >     
> > >   
> > > >  ;; AUTHORITY SECTION:    
> > >   
> > > >  wsly.de. 86400 IN NS art.ns.cloudflare.com.    
> > >   
> > > >  wsly.de. 86400 IN NS roxy.ns.cloudflare.com.    
> > >   
> > >
> > >
> > >     
> > >   
> > > >  I was confused, since I have changed the domain's nameservers to    
> > >   
> > > >  cloudflare's, why .de's root servers still give the clues that I am using    
> > >   
> > > >  ns[1-4].alldomains.hosting?    
> > >   
> > >
> > >
> > >     
> > >   
> > > In order to update the records in "de" you need your domain provider to send    
> > >   
> > > them an update of the nameservers.    
> > >   
> > >
> > >
> > >     
> > >   
> > > - Elmar.    
> > >   
> > >
> > >   
> >   
> >   
> >   
> >   
>   
>   
>   
>   
>   
  
  
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191125/ce9c85a9/attachment.html>

From postmaster at wsly.de  Mon Nov 25 15:09:33 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Mon, 25 Nov 2019 23:09:33 +0800
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <20191125141013.GB34850@straasha.imrryr.org>
Message-ID: <41f33b0f-47fb-479e-b506-6c547616df94@pengyonghuade-iPhone>

     
 

 Thanks for updating the info Victor.
 

 
 

 
 
>  
> On Nov 25, 2019 at 10:10 PM,  <Viktor Dukhovni (mailto:ietf-dane at dukhovni.org)>  wrote:
>  
>  
>  
>  On Mon, Nov 25, 2019 at 02:56:51PM +0100, Elmar K. Bins wrote: 
>
> >   >  ;; AUTHORITY SECTION: 
> >   >  wsly.de. 86400 IN NS art.ns.cloudflare.com. 
> >   >  wsly.de. 86400 IN NS roxy.ns.cloudflare.com. 
> >  
> >  In order to update the records in "de" you need your domain provider to send 
> >  them an update of the nameservers. 
>
> More precisely, the registrar rather than the DNS operator when these 
> are different. But in this case no need, the .de glue has already been 
> updated: 
>
>  wsly.de. IN NS art.ns.cloudflare.com. 
>  wsly.de. IN NS roxy.ns.cloudflare.com. 
>
> and WHOIS reports: 
>
>  Domain: wsly.de 
>  Nserver: art.ns.cloudflare.com 
>  Nserver: roxy.ns.cloudflare.com 
>  Changed: 2019-11-25T13:20:29+01:00 
>
> -- 
>  Viktor. 
> _______________________________________________ 
> 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/20191125/c6c10fd9/attachment.html>

From mallman at icir.org  Mon Nov 25 20:30:32 2019
From: mallman at icir.org (Mark Allman)
Date: Mon, 25 Nov 2019 15:30:32 -0500
Subject: [dns-operations] root?  we don't need no stinkin' root!
Message-ID: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>


Left here to be ripped apart ... :-)

  Mark Allman. On Eliminating Root Nameservers from the DNS, ACM
  SIGCOMM Workshop on Hot Topics in Networks (HotNets), November
  2019.
  https://www.icir.org/mallman/pubs/All19b/

  Abstract:
    The Domain Name System (DNS) leverages nearly 1K distributed
    servers to provide information about the root of the Internet's
    namespace. The large size and broad distribution of the root
    nameserver infrastructure has a number of benefits, including
    providing robustness, low delays to topologically close root
    servers and a way to cope with the immense torrent of queries
    destined for the root nameservers. While the root nameserver
    service operates well, it represents a large community
    investment. Due to this large cost, in this paper we take the
    position that DNS' root nameservers should be
    eliminated. Instead, recursive resolvers should use a local copy
    of the root zone file instead of consulting root
    nameservers. This paper considers the pros and cons of this
    alternate approach.

allman


--
https://www.icir.org/mallman/
@mallman_icsi

From fw at deneb.enyo.de  Mon Nov 25 20:54:55 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 25 Nov 2019 21:54:55 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> (Mark Allman's
 message of "Mon, 25 Nov 2019 15:30:32 -0500")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
Message-ID: <878so3oew0.fsf@mid.deneb.enyo.de>

* Mark Allman:

> Left here to be ripped apart ... :-)

The query numbers are surprisingly low.  To me at last.

Do we know why the number of root instances has increased?  Is it
because of the incoming data is interesting?

From bert.hubert at powerdns.com  Mon Nov 25 21:22:12 2019
From: bert.hubert at powerdns.com (bert hubert)
Date: Mon, 25 Nov 2019 22:22:12 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <878so3oew0.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
Message-ID: <20191125212212.GB25479@server.ds9a.nl>

On Mon, Nov 25, 2019 at 09:54:55PM +0100, Florian Weimer wrote:
> Do we know why the number of root instances has increased?  Is it
> because of the incoming data is interesting?

I would venture the latter. This remains a seriously underdiscussed subject. 

There is of course "logging of all data" which is bad enough but people
appear to be getting creative with doing "analyses on the 24 hours of logs
we are allowed to keep".

	Bert

From woody at pch.net  Mon Nov 25 21:23:40 2019
From: woody at pch.net (Bill Woodcock)
Date: Mon, 25 Nov 2019 22:23:40 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <878so3oew0.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
Message-ID: <330051A6-AE60-47C5-A97B-A4D305636C01@pch.net>



> On Nov 25, 2019, at 9:54 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> The query numbers are surprisingly low.  To me at last.

Duane Wessels did a good study some time ago of queries to the root.  I believe over 99% were bogus, not real queries for resolvable things.

> Do we know why the number of root instances has increased?  Is it
> because of the incoming data is interesting?

In some cases perhaps.  In our case, we typically install eight at each location, and we?ve passed two hundred locations now.  So this:

>    The Domain Name System (DNS) leverages nearly 1K distributed
>    servers

?is not exactly correct?  Perhaps it?s only 1K _locations_.

We provide them to make the root more resilient against DDoS, and to reduce query latency.  But we?re a non-profit which exists for that purpose, we don?t derive any revenue from it, and our finances are publicly audited.  For-profits require revenue, and there?s certainly a market for pcaps taken from in front of root servers.

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191125/ea0bf607/attachment.sig>

From jim at rfc1035.com  Mon Nov 25 21:39:32 2019
From: jim at rfc1035.com (Jim Reid)
Date: Mon, 25 Nov 2019 21:39:32 +0000
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <878so3oew0.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
Message-ID: <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>



> On 25 Nov 2019, at 20:54, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> The query numbers are surprisingly low.  To me at last.

What do you consider to be a lot of queries? The root server system collectively handles 500K-1M queries per second. That seems rather a lot to me. YMMV. I don't know of any other IT platform that reliably handles transactions at anything close to that volume. Or orders of magnitude lower. IIUC Mastercard and Visa each handle around "only" 30K transactions/second.

Root server query numbers are continually rising. This is why suggestions like Mark's and RFC7706 need careful consideration. Ultimately, the root server operators won't be able to keep on adding capacity and bandwidth to keep up with demand or mitigate DDoS attacks. They'll eventually run out of money/bits/hardware before the script kiddies and their botnets do. Even though the RSOs are winning that arms race today.

> Do we know why the number of root instances has increased?

Partly it will be each RSO adding more instances to improve resilience, capacity and performance. They will also be adding more servers to address layer 9+ questions from countries who want to have more root servers inside their borders. IXPs/ISPs want that too, just like they want extra copies of local cache nodes from CDNs.

Some countries perceive the DNS root to be US-centric. When they're not on friendly terms with the USA, that can be a problem. Adding anycast root instances in say China or Russia can go some way to alleviate some of those concerns.

> Is it because of the incoming data is interesting?

Define interesting. IMO instances are being added for the reasons above. Whether the ever-growing volume of queries to the root is interesting or not is irrelevant IMO.



From fw at deneb.enyo.de  Mon Nov 25 22:19:36 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 25 Nov 2019 23:19:36 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com> (Jim Reid's
 message of "Mon, 25 Nov 2019 21:39:32 +0000")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
Message-ID: <87tv6rmwef.fsf@mid.deneb.enyo.de>

* Jim Reid:

>> On 25 Nov 2019, at 20:54, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> The query numbers are surprisingly low.  To me at last.
>
> What do you consider to be a lot of queries? The root server system
> collectively handles 500K-1M queries per second. That seems rather a
> lot to me. YMMV.

But globally?  For the entire planet?

It's certainly beyond what I can run out of my basement using spare
parts, but it's also not a mindbogglingly huge number.  I would have
expected something that's clearly impossible to handle from a single
box.

>> Is it because of the incoming data is interesting?
>
> Define interesting.

The data could have monetary value.  Passwords that are otherwise
difficult to come by might be leaking.

From list-dns-operations at dragon.net  Mon Nov 25 22:31:49 2019
From: list-dns-operations at dragon.net (Paul Ebersman)
Date: Mon, 25 Nov 2019 14:31:49 -0800
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <87tv6rmwef.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
Message-ID: <20191125223149.B3EE019AD672@fafnir.remote.dragon.net>

jim> What do you consider to be a lot of queries? The root server system
jim> collectively handles 500K-1M queries per second. That seems rather
jim> a lot to me. YMMV.

fw> But globally?  For the entire planet?

fw> It's certainly beyond what I can run out of my basement using spare
fw> parts, but it's also not a mindbogglingly huge number.  I would have
fw> expected something that's clearly impossible to handle from a single
fw> box.

Actually, it's a great argument for longer TTLs and caching doing what
they're supposed to.

The root zones and most TLDs tend to have longer, non trendy (over 5
minute) TTLs, so root servers, TLDs and other auth servers get orders of
magnitude less queries than large recursive farms, which cache and then
get cache hits.

Comcast & Google get 2-3 orders of magnitude more than large TLD servers
and 4-5 orders of magnitude more than the root servers and these two
probably represent something like 1/3 of public recursive server
traffic. The largest Chinese ISP used to do more traffic then either of
the above.

But compared to a large corp DNS server farm, the root servers shovel a
lot of bits. Some of it even valid DNS queries and responses. ;)

From m3047 at m3047.net  Mon Nov 25 23:05:14 2019
From: m3047 at m3047.net (Fred Morris)
Date: Mon, 25 Nov 2019 15:05:14 -0800 (PST)
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87tv6rmwef.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
Message-ID: <alpine.LSU.2.21.1911251444380.7597@flame.m3047>

Funny you should mention this. It just occurred to me, although it also 
apparently occurred to one other soul on the dnsrpz mailing list, you can 
use RPZ to audit and to some extent contain leakage.

Assuming you own example.com, I'm speaking about entries akin to the 
following:

*.example.example.com CNAME .
*.com.example.com CNAME .
*.net.example.com CNAME .

Entries like the foregoing will return NXDOMAIN for, for example,
dolphin2.com.example.com. ;-) It's also possible to log or direct the 
querant to a honeypot. Granted, most likely the stub resolver is trying 
dolphin2.com.example.com because it already tried dolphin2 and 
dolphin2.com and both of those failed, but at least you know.

You can also see just how good your passive DNS provider's data is, by 
looking for things which resolved to 127.0.53.53. (This is a really good 
way for the casual reader to understand the scope of this problem, by the 
way.)

Running your own caching resolver and dumping the cache and looking for 
stuff is also occasionally advisable; I suspect most of the people on this 
list would know this.

--

Fred Morris

On Mon, 25 Nov 2019, Florian Weimer wrote:
>
>>> Is it because of the incoming data is interesting?
>>
>> Define interesting.
>
> The data could have monetary value.  Passwords that are otherwise
> difficult to come by might be leaking.

From postmaster at wsly.de  Tue Nov 26 00:53:12 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Tue, 26 Nov 2019 08:53:12 +0800
Subject: [dns-operations] Questions about my domain's DNS
In-Reply-To: <20191125143822.GK57997@x11672.adm.denic.de>
References: <20191125135651.zptxv2apqbheroi4@ekbbook.local>
 <154dd766-b6fe-410d-bbd1-50b6959a9995@pengyonghuade-iPhone>
 <20191125143822.GK57997@x11672.adm.denic.de>
Message-ID: <8f45f9aa-2c87-3990-7954-490cbe1b5895@wsly.de>

Thank you for instant support Peter. I love DENIC.

on 2019/11/25 22:38, Peter Koch wrote:
> without knowing details about the registrar/reseller chain that you might be
> using, informing the registrar of such a change is a prerequisite for the
> delegation to change at the TLD level.  That means, the registrar will
> change the respective entries in the TLD registry.  In the case of DE,
> the current (sic!) cadence of zone publication is once per hour, which makes you
> incur a delay of up to two ours in the worst case.  Meanwhile, your changes
> have made it into the DE zone (as published trough the DE TLD nameservers).

Regards.

From postmaster at wsly.de  Tue Nov 26 00:57:28 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Tue, 26 Nov 2019 08:57:28 +0800
Subject: [dns-operations] Questions on private nameservers registration
Message-ID: <38789521-8b38-03ea-b818-0cc9c8019b62@wsly.de>

Hello

If I want to run my own nameservers, saying they are:

ns1.wsly.de.   1.2.3.4
ns2.wsly.de.   5.6.7.8


Would I put the glues into DE's registry, or shall I put glues into all 
registries, including  COM, NET, INFO, ccTLD etc?

Thanks.

From postmaster at wsly.de  Tue Nov 26 01:41:07 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Tue, 26 Nov 2019 09:41:07 +0800
Subject: [dns-operations] Questions on private nameservers registration
In-Reply-To: <36d36e82-05d9-9344-b8ad-ee05c02d1083@saltant.com>
References: <38789521-8b38-03ea-b818-0cc9c8019b62@wsly.de>
 <36d36e82-05d9-9344-b8ad-ee05c02d1083@saltant.com>
Message-ID: <fad7245e-7f9f-d90c-2f08-c776e75ec05b@wsly.de>

John,

on 2019/11/26 9:35, John W. O'Brien wrote:
> Are ns{1,2}.wsly.de authoritative for wsly.de? Then glue is required in
> DE. Otherwise probably not [0].

Yes I plan to setup ns{1,2}.wsly.de to be wsly.de's auth-nameservers.
Thank you for pointing out that.

Regards.

From john at saltant.com  Tue Nov 26 01:35:34 2019
From: john at saltant.com (John W. O'Brien)
Date: Mon, 25 Nov 2019 20:35:34 -0500
Subject: [dns-operations] Questions on private nameservers registration
In-Reply-To: <38789521-8b38-03ea-b818-0cc9c8019b62@wsly.de>
References: <38789521-8b38-03ea-b818-0cc9c8019b62@wsly.de>
Message-ID: <36d36e82-05d9-9344-b8ad-ee05c02d1083@saltant.com>

On 2019/11/25 19:57, Wesley Peng wrote:
> If I want to run my own nameservers, saying they are:
>
> ns1.wsly.de.   1.2.3.4
> ns2.wsly.de.   5.6.7.8
>
>
> Would I put the glues into DE's registry, or shall I put glues into all
> registries, including  COM, NET, INFO, ccTLD etc?

You would publish glue records to DE, and not to any of the others you
mentioned. The only situations where glue records are required (or even
useful) are when a resolver would be unable to traverse a referral
without them. That is, when a nameserver's name is in-baliwick of a zone
for which it is itself authoritative.

Are ns{1,2}.wsly.de authoritative for wsly.de? Then glue is required in
DE. Otherwise probably not [0].

[0] It would be theoretically possible for some other servers to be
authoritative for wsly.de while ns1.wsly.de is authoritative for
ns1.wsly.de and ns2.wsly.de is authoritative for ns2.wsle.de. In that
case, you would need glue in WSLY.DE and not in DE, but it would be very
unusual to do this in the first place and other DNS operators might look
at you funny.

-- 
John W. O'Brien
OpenPGP keys:
    0x33C4D64B895DBF3B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191125/e7939e48/attachment-0001.sig>

From ietf-dane at dukhovni.org  Tue Nov 26 04:27:51 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 25 Nov 2019 23:27:51 -0500
Subject: [dns-operations] Quad9 denial of existence for
 _25._tcp.mx1.p01.antagonist.nl IN TLSA
Message-ID: <20191126042751.GD34850@straasha.imrryr.org>


According DNSViz, and the Cloudflare, Google and Verisign public resolvers the
qname below has a TLSA record, but Quad returns an apparently valid denial of
existence.  It is possible that Quad9 is "the guilty party" here only by
accident, and had I asked at another time, some other server would return the
unexpected denial of existence.

No idea where the associated RRSIGs and NSEC3 records are coming from.  Perhaps
there are some nameservers (reached via Quad9) for antagonist.nl that have a
zone file in which the empty-non-terminal "_tcp" is missing...

    $ dig +dnssec +noall +comment +ans +auth -t tlsa _25._tcp.mx1.p01.antagonist.nl @9.9.9.10
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10642
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 512
    ;; AUTHORITY SECTION:
    antagonist.nl.          180     IN      SOA     ns1.antagonist.nl. hostmaster.antagonist.nl. 2018052300 180 3600 1209600 86400
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 43200 IN NSEC3 1 0 1 AB D04COHDERT50P43FHSP1N5F7LDVTORH7 A AAAA RRSIG
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 43200 IN NSEC3 1 0 1 AB IDTV8EDH9FRO5UU2OC4N3PUM51SRLDGH A RRSIG
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 43200 IN NSEC3 1 0 1 AB GFL0IAO83UJDAA6IHCTHFGL6T4KNILQO A RRSIG
    antagonist.nl.          180     IN      RRSIG   SOA 13 2 180 20191205000000 20191114000000 47684 antagonist.nl. TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. 5KPt3wExlfKg4tZJ1fdR1xhnj8x8DsmgYR2+pCHkcc041thw3E6jQCfY CESVytcQcp6Zb/uJ3zxNXExJkEzZoQ==
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. Wrzps6dY9zhq14kBiFp0KwDqdkMtceOMV2cMKPkznhxFcsmpsTazZX1Z MAw/565cRwpWRoU5LuGNzGHg3ZstUQ==
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. DBJvz7HbYSFS/PHtTXD2qMwsKuWXoqNj8MPNMIk84Jv4kY1w52EevWIS nIgDknp9DbzYcczQzOOu1cyEYulYPg==

    6d1aa3h9jtqjdp0vjblqej9e17ub81hs. _25._tcp.mx1.p01.antagonist.nl
    v3rrfku7an9uo5qeuhbdndnruhp9esar. *._tcp.mx1.p01.antagonist.nl
    i9sp4p909spoci68n9q0r33hk9fes0n4. _tcp.mx1.p01.antagonist.nl    (Covered)
    g90cq1j49b7nkrom5lcojqals2gittit. *.mx1.p01.antagonist.nl       (Covered)
    cueh7hkbnbrqk65590909p4r0pq6cd45. mx1.p01.antagonist.nl         (Covered, closest encloser)
    sac7gh66m6avf55q05gbfhh91a48hstf. *.p01.antagonist.nl
    iupnvfafqalai3eke44m2vi4vr89lgpk. p01.antagonist.nl
    83jtudmler6j6tailr1f6hktosq1mvc4. *.antagonist.nl
    29eiirrkt62jjrrigm5ouurhdt4p682u. antagonist.nl

-- 
    Viktor.

From jim at rfc1035.com  Tue Nov 26 08:58:43 2019
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 26 Nov 2019 08:58:43 +0000
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87tv6rmwef.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
Message-ID: <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>



> On 25 Nov 2019, at 22:19, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
>> What do you consider to be a lot of queries? The root server system
>> collectively handles 500K-1M queries per second. That seems rather a
>> lot to me. YMMV.
> 
> But globally?  For the entire planet?

Yes. If you consider a well-behaved recursive resolver would only query the root a few times a day (probably < 10), a query load of 0.5-1M/second seems on the high side, even for the whole planet.

> The data could have monetary value.

Could. But nobody's selling those data. And that's probably illegal anyway thanks to GDPR.

> Passwords that are otherwise difficult to come by might be leaking.

Good luck finding those in amongst the terabytes of dross that hits the root every day.



From jim at rfc1035.com  Tue Nov 26 09:07:55 2019
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 26 Nov 2019 09:07:55 +0000
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <20191125223149.B3EE019AD672@fafnir.remote.dragon.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <20191125223149.B3EE019AD672@fafnir.remote.dragon.net>
Message-ID: <0CE95B73-B4DF-45B9-92FF-66C85695BA84@rfc1035.com>



> On 25 Nov 2019, at 22:31, Paul Ebersman <list-dns-operations at dragon.net> wrote:
> 
> Actually, it's a great argument for longer TTLs and caching doing what
> they're supposed to.

It would be if the root only got queries from well behaved recursive resolvers. But we both know Paul that simply isn't true.

Well over 90% of the query traffic at the root has no reason to be going there at all. For instance stub resolvers that don't care about TTLs or do any sort of caching, Chrome's 10-character nonce strings to detect NXDOMAIN rewriting, CPE querying for .home, enterprises leaking queries for .corp, etc, etc.

The amount and breadth of the crap that hits the root is staggering. I suppose that'll also be true for the recursive service offered by the likes of google or Comcast.

From fw at deneb.enyo.de  Tue Nov 26 09:16:16 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 26 Nov 2019 10:16:16 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com> (Jim Reid's
 message of "Tue, 26 Nov 2019 08:58:43 +0000")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
Message-ID: <87zhgjgfq7.fsf@mid.deneb.enyo.de>

* Jim Reid:

>> On 25 Nov 2019, at 22:19, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>>> What do you consider to be a lot of queries? The root server system
>>> collectively handles 500K-1M queries per second. That seems rather a
>>> lot to me. YMMV.
>> 
>> But globally?  For the entire planet?
>
> Yes. If you consider a well-behaved recursive resolver would only
> query the root a few times a day (probably < 10), a query load of
> 0.5-1M/second seems on the high side, even for the whole planet.

Up until recently, well-behaved recursive resolvers had to forward
queries to the root if they were not already covered by a delegation.
RFC 7816 and in particular RFC 8198 changed that, but before that, it
was just how the protocol was expected to work.

From jim at rfc1035.com  Tue Nov 26 10:33:31 2019
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 26 Nov 2019 10:33:31 +0000
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87zhgjgfq7.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
Message-ID: <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>



> On 26 Nov 2019, at 09:16, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> Up until recently, well-behaved recursive resolvers had to forward
> queries to the root if they were not already covered by a delegation.
> RFC 7816 and in particular RFC 8198 changed that, but before that, it
> was just how the protocol was expected to work.

So what? These RFCs make very little difference to the volume of queries a resolving server will send to the root. QNAME minimisation has no impact at all: the root just sees a query for .com instead of foobar.com. A recursive resolver should already be supporting negative caching and will have a reasonably complete picture of what's in (or not in) the root. RFC8198 will of course help that but not by much IMO.




From fw at deneb.enyo.de  Tue Nov 26 11:01:47 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 26 Nov 2019 12:01:47 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com> (Jim Reid's
 message of "Tue, 26 Nov 2019 10:33:31 +0000")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
Message-ID: <87k17mhpes.fsf@mid.deneb.enyo.de>

* Jim Reid:

>> On 26 Nov 2019, at 09:16, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> Up until recently, well-behaved recursive resolvers had to forward
>> queries to the root if they were not already covered by a delegation.
>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>> was just how the protocol was expected to work.
>
> So what? These RFCs make very little difference to the volume of
> queries a resolving server will send to the root. QNAME minimisation
> has no impact at all: the root just sees a query for .com instead of
> foobar.com.

QNAME minimization allows a resolver to blacklist (say) the CORP
subtree, based on the NXDOMAIN response for CORP.  If the full query
is sent to the root, it is only possible to cache the NXDOMAIN for the
exact QNAME, and not its siblings.  (This assumes that the root deals
with empty non-terminals in the expected way, but that seems to be a
reasonable assumption for the root zone.)

From drc at virtualized.org  Tue Nov 26 11:46:37 2019
From: drc at virtualized.org (David Conrad)
Date: Tue, 26 Nov 2019 12:46:37 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
Message-ID: <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>

On Nov 26, 2019, at 11:33 AM, Jim Reid <jim at rfc1035.com> wrote:
>> On 26 Nov 2019, at 09:16, Florian Weimer <fw at deneb.enyo.de <mailto:fw at deneb.enyo.de>> wrote:
>> 
>> Up until recently, well-behaved recursive resolvers had to forward
>> queries to the root if they were not already covered by a delegation.
>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>> was just how the protocol was expected to work.
> 
> So what? These RFCs make very little difference to the volume of queries a resolving server will send to the root. QNAME minimisation has no impact at all: the root just sees a query for .com instead of foobar.com <http://foobar.com/>. A recursive resolver should already be supporting negative caching and will have a reasonably complete picture of what's in (or not in) the root. RFC8198 will of course help that but not by much IMO.

It would appear a rather large percentage of queries to the root (like 50% in some samples) are random strings, between 7 to 15 characters long, sometimes longer.  I believe this is Chrome-style probing to determine if there is NXDOMAIN redirection. A good example of the tragedy of the commons, like water pollution and climate change.

If resolvers would enable DNSSEC validation, there would, in theory, be a reduction in these queries due to aggressive NSEC caching.  Of course, practice may not match theory (https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf).

Of course, steady state query load is largely irrelevant since root service has to be provisioned with massive DDoS in mind. In my personal view, the deployment of additional anycast instances by the root server operators is a useful stopgap, but ultimately, given the rate of growth of DoS attack capacity (and assuming that growth will continue due to the stunning security practices of IoT device manufacturers), stuff like what is discussed in that paper is the right long term strategy.

Regards,
-drc
(Speaking for myself)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191126/497669c9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191126/497669c9/attachment-0001.sig>

From mallman at icir.org  Tue Nov 26 13:41:51 2019
From: mallman at icir.org (Mark Allman)
Date: Tue, 26 Nov 2019 08:41:51 -0500
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
Message-ID: <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>


Let me try to get away from what is or is not "big" and ask two
questions.  (These are legit questions to me.  I have studied the
DNS a whole bunch, but I do not operate any non-trivial part of the
DNS and so that viewpoint is valuable to me.)

(1) Setting aside history and how things have been done and why
    (which I am happy to stipulate is rational)... At this point,
    are there tangible benefits for getting information about the
    TLD nameservers to resolvers as needed via a network service?

(2) Are there fundamental problems that would arise in recursive
    resolvers if the information about TLD nameservers was no longer
    available via a network service, but instead had to come from a
    file that was snarfed periodically?

Thanks!

allman


--
https://www.icir.org/mallman/
@mallman_icsi

From woody at pch.net  Tue Nov 26 13:46:30 2019
From: woody at pch.net (Bill Woodcock)
Date: Tue, 26 Nov 2019 14:46:30 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
References: <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
Message-ID: <34279C23-0AAC-4725-AF2B-D496B4BDB54B@pch.net>

Yes, in the long term you can only survive by being both large and clever, not just one or the other. 
    
                -Bill


> On Nov 26, 2019, at 13:03, David Conrad <drc at virtualized.org> wrote:
> 
> ?On Nov 26, 2019, at 11:33 AM, Jim Reid <jim at rfc1035.com> wrote:
>>> On 26 Nov 2019, at 09:16, Florian Weimer <fw at deneb.enyo.de> wrote:
>>> 
>>> Up until recently, well-behaved recursive resolvers had to forward
>>> queries to the root if they were not already covered by a delegation.
>>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>>> was just how the protocol was expected to work.
>> 
>> So what? These RFCs make very little difference to the volume of queries a resolving server will send to the root. QNAME minimisation has no impact at all: the root just sees a query for .com instead of foobar.com. A recursive resolver should already be supporting negative caching and will have a reasonably complete picture of what's in (or not in) the root. RFC8198 will of course help that but not by much IMO.
> 
> It would appear a rather large percentage of queries to the root (like 50% in some samples) are random strings, between 7 to 15 characters long, sometimes longer.  I believe this is Chrome-style probing to determine if there is NXDOMAIN redirection. A good example of the tragedy of the commons, like water pollution and climate change.
> 
> If resolvers would enable DNSSEC validation, there would, in theory, be a reduction in these queries due to aggressive NSEC caching.  Of course, practice may not match theory (https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf). 
> 
> Of course, steady state query load is largely irrelevant since root service has to be provisioned with massive DDoS in mind. In my personal view, the deployment of additional anycast instances by the root server operators is a useful stopgap, but ultimately, given the rate of growth of DoS attack capacity (and assuming that growth will continue due to the stunning security practices of IoT device manufacturers), stuff like what is discussed in that paper is the right long term strategy.
> 
> Regards,
> -drc
> (Speaking for myself)
> 
> _______________________________________________
> 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/20191126/4a1180cf/attachment.html>

From mallman at icir.org  Tue Nov 26 13:49:08 2019
From: mallman at icir.org (Mark Allman)
Date: Tue, 26 Nov 2019 08:49:08 -0500
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
 <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
Message-ID: <1414A4F6-C45A-49B3-880F-B722DB80839C@icsi.berkeley.edu>


> It would appear a rather large percentage of queries to the root
> (like 50% in some samples) are random strings, between 7 to 15
> characters long, sometimes longer.  I believe this is Chrome-style
> probing to determine if there is NXDOMAIN redirection. A good
> example of the tragedy of the commons, like water pollution and
> climate change.

I will note that there have been quite a number of studies over the
last 20 years that show > 95% of the queries are junk of one kind or
another.  Someone mentioned Duane's nice paper.  But, this
observation started with Brownlee, et.al.'s 2001 paper.  Point
being, Chrome might cause some of this now, but it has been there
long before Chrome started this particularly probing.

What's more... in my rudimentary poking of the DITL data [*] it
seems that 25-50% of the "resolvers" that query the root *never*
send a legit query.  I.e., we can't ascribe a lot of this junk to
resolvers that could just work better somehow.

[*] There may be numbers on this sort of thing in the Brownlee,
    Wessels, etc. papers ... I just can't recall them off the top of
    my head.

allman

--
https://www.icir.org/mallman/
@mallman_icsi

From martijn at reening.net  Tue Nov 26 13:41:26 2019
From: martijn at reening.net (Martijn Reening)
Date: Tue, 26 Nov 2019 14:41:26 +0100
Subject: [dns-operations] Quad9 denial of existence for
 _25._tcp.mx1.p01.antagonist.nl IN TLSA
In-Reply-To: <20191126042751.GD34850@straasha.imrryr.org>
References: <20191126042751.GD34850@straasha.imrryr.org>
Message-ID: <b6e68d8d-e1b3-08ef-c7fd-ec8b39f2c9dd@reening.net>

Hello Viktor,

We haven't changed anything on our side in the past days, but I see the expected response from Quad9 now:

$ dig +dnssec +noall +comment +ans +auth -t tlsa _25._tcp.mx1.p01.antagonist.nl @9.9.9.10
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17089
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; ANSWER SECTION:
_25._tcp.mx1.p01.antagonist.nl.??? 300 IN??? TLSA??? 2 1 1 E12D92CF8D801D0FDB21BEDEE1CEC09C15AC2A61E27FA27D6B151312 D2206520
_25._tcp.mx1.p01.antagonist.nl.??? 300 IN??? RRSIG??? TLSA 13 6 300 20191205000000 20191114000000 47684 antagonist.nl. XDMVKwb3MHIwGpRd/sCctO2Jy+VyqdVbmsHnmyhtOwB0WiZ7a73WAFat 6QOmM53ty4Q6YjpBb+lIHInFR8BAjQ==

I checked our nameservers for the proper ENT responses and there do not seem to be any abnormalities.
Do you still see this error, or perhaps know something else to check?

On 26/11/2019 05:27, Viktor Dukhovni wrote:
>
> According DNSViz, and the Cloudflare, Google and Verisign public resolvers the
> qname below has a TLSA record, but Quad returns an apparently valid denial of
> existence.? It is possible that Quad9 is "the guilty party" here only by
> accident, and had I asked at another time, some other server would return the
> unexpected denial of existence.
>
> No idea where the associated RRSIGs and NSEC3 records are coming from.? Perhaps
> there are some nameservers (reached via Quad9) for antagonist.nl that have a
> zone file in which the empty-non-terminal "_tcp" is missing...
>
> ??? $ dig +dnssec +noall +comment +ans +auth -t tlsa _25._tcp.mx1.p01.antagonist.nl @9.9.9.10
> ??? ;; Got answer:
> ??? ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10642
> ??? ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
>
> ??? ;; OPT PSEUDOSECTION:
> ??? ; EDNS: version: 0, flags: do; udp: 512
> ??? ;; AUTHORITY SECTION:
> ??? antagonist.nl.????????? 180???? IN????? SOA???? ns1.antagonist.nl. hostmaster.antagonist.nl. 2018052300 180 3600 1209600 86400
> ??? cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 43200 IN NSEC3 1 0 1 AB D04COHDERT50P43FHSP1N5F7LDVTORH7 A AAAA RRSIG
> ??? i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 43200 IN NSEC3 1 0 1 AB IDTV8EDH9FRO5UU2OC4N3PUM51SRLDGH A RRSIG
> ??? g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 43200 IN NSEC3 1 0 1 AB GFL0IAO83UJDAA6IHCTHFGL6T4KNILQO A RRSIG
> ??? antagonist.nl.????????? 180???? IN????? RRSIG?? SOA 13 2 180 20191205000000 20191114000000 47684 antagonist.nl. TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
> ??? cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. 5KPt3wExlfKg4tZJ1fdR1xhnj8x8DsmgYR2+pCHkcc041thw3E6jQCfY CESVytcQcp6Zb/uJ3zxNXExJkEzZoQ==
> ??? i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. Wrzps6dY9zhq14kBiFp0KwDqdkMtceOMV2cMKPkznhxFcsmpsTazZX1Z MAw/565cRwpWRoU5LuGNzGHg3ZstUQ==
> ??? g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. DBJvz7HbYSFS/PHtTXD2qMwsKuWXoqNj8MPNMIk84Jv4kY1w52EevWIS nIgDknp9DbzYcczQzOOu1cyEYulYPg==
>
> ??? 6d1aa3h9jtqjdp0vjblqej9e17ub81hs. _25._tcp.mx1.p01.antagonist.nl
> ??? v3rrfku7an9uo5qeuhbdndnruhp9esar. *._tcp.mx1.p01.antagonist.nl
> ??? i9sp4p909spoci68n9q0r33hk9fes0n4. _tcp.mx1.p01.antagonist.nl??? (Covered)
> ??? g90cq1j49b7nkrom5lcojqals2gittit. *.mx1.p01.antagonist.nl?????? (Covered)
> ??? cueh7hkbnbrqk65590909p4r0pq6cd45. mx1.p01.antagonist.nl???????? (Covered, closest encloser)
> ??? sac7gh66m6avf55q05gbfhh91a48hstf. *.p01.antagonist.nl
> ??? iupnvfafqalai3eke44m2vi4vr89lgpk. p01.antagonist.nl
> ??? 83jtudmler6j6tailr1f6hktosq1mvc4. *.antagonist.nl
> ??? 29eiirrkt62jjrrigm5ouurhdt4p682u. antagonist.nl
>

-- 
Kind regards,
Met vriendelijke groet,

Martijn Reening
Systems and Network Engineer


From roy at dnss.ec  Tue Nov 26 14:46:05 2019
From: roy at dnss.ec (Roy Arends)
Date: Tue, 26 Nov 2019 15:46:05 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <1414A4F6-C45A-49B3-880F-B722DB80839C@icsi.berkeley.edu>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
 <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
 <1414A4F6-C45A-49B3-880F-B722DB80839C@icsi.berkeley.edu>
Message-ID: <9FDE12E1-1B0E-4558-B57D-48A5F8998334@dnss.ec>

Mark

> On 26 Nov 2019, at 14:49, Mark Allman <mallman at icir.org> wrote:
> 
> 
>> It would appear a rather large percentage of queries to the root
>> (like 50% in some samples) are random strings, between 7 to 15
>> characters long, sometimes longer.  I believe this is Chrome-style
>> probing to determine if there is NXDOMAIN redirection. A good
>> example of the tragedy of the commons, like water pollution and
>> climate change.
> 
> I will note that there have been quite a number of studies over the
> last 20 years that show > 95% of the queries are junk of one kind or
> another.  Someone mentioned Duane's nice paper.  But, this
> observation started with Brownlee, et.al.'s 2001 paper.  Point
> being, Chrome might cause some of this now, but it has been there
> long before Chrome started this particularly probing.

Chrome might cause some of this? That is quite an understatement. If the number is around 50%, it is not "some of this". If this 50% disappears, the rest of the crap will still be there, and will probably be still > 90 %.

> What's more... in my rudimentary poking of the DITL data [*] it
> seems that 25-50% of the "resolvers" that query the root *never*
> send a legit query.  I.e., we can't ascribe a lot of this junk to
> resolvers that could just work better somehow.

and what percentage of traffic do these 25-50% resolvers account for? 

Roy

> 
> [*] There may be numbers on this sort of thing in the Brownlee,
>    Wessels, etc. papers ... I just can't recall them off the top of
>    my head.
> 
> allman
> 
> --
> https://www.icir.org/mallman/
> @mallman_icsi
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



From roy at dnss.ec  Tue Nov 26 15:04:13 2019
From: roy at dnss.ec (Roy Arends)
Date: Tue, 26 Nov 2019 16:04:13 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
 <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
Message-ID: <FD9E58CF-1171-4209-B927-A7097E862D36@dnss.ec>



> On 26 Nov 2019, at 12:46, David Conrad <drc at virtualized.org> wrote:
> 
> It would appear a rather large percentage of queries to the root (like 50% in some samples) are random strings, between 7 to 15 characters long, sometimes longer.  I believe this is Chrome-style probing to determine if there is NXDOMAIN redirection. A good example of the tragedy of the commons, like water pollution and climate change.

Yep.

https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3/chrome/browser/intranet_redirect_detector.cc
Line 79: "// We generate a random hostname with between 7 and 15 characters.?

https://ithi.research.icann.org/graph-m3.html
Table "Queries to frequently found name patterns? shows that the frequency distribution for queries between 7 and 15 characters are near flat (around 5.2% per character length) AND an order higher than ANY other queries.

?Coincidence? I think NOT!?  

https://youtu.be/MDpuTqBI0RM?t=53

Roy



From ietf-dane at dukhovni.org  Tue Nov 26 15:09:38 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 26 Nov 2019 10:09:38 -0500
Subject: [dns-operations] Quad9 denial of existence for
 _25._tcp.mx1.p01.antagonist.nl IN TLSA
In-Reply-To: <b6e68d8d-e1b3-08ef-c7fd-ec8b39f2c9dd@reening.net>
References: <20191126042751.GD34850@straasha.imrryr.org>
 <b6e68d8d-e1b3-08ef-c7fd-ec8b39f2c9dd@reening.net>
Message-ID: <20191126150938.GF34850@straasha.imrryr.org>

On Tue, Nov 26, 2019 at 02:41:26PM +0100, Martijn Reening wrote:

> We haven't changed anything on our side in the past days, but I see the
> expected response from Quad9 now:
> 
> $ dig +dnssec +noall +comment +ans +auth -t tlsa _25._tcp.mx1.p01.antagonist.nl @9.9.9.10
> _25._tcp.mx1.p01.antagonist.nl.??? 300 IN??? TLSA??? 2 1 1 E12D92CF8D801D0FDB21BEDEE1CEC09C15AC2A61E27FA27D6B151312 D2206520
> 
> I checked our nameservers for the proper ENT responses and there do not seem
> to be any abnormalities.  Do you still see this error, or perhaps know
> something else to check?

Yes, I still the DoE response from 9.9.9.10, and also (not always) from
its peer 149.112.112.10:

    $ dig +dnssec +noall +comment +ans +auth -t tlsa _25._tcp.mx1.p01.antagonist.nl @149.112.112.10
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1327
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 512
    ;; AUTHORITY SECTION:
    antagonist.nl.          180     IN      SOA     ns1.antagonist.nl. hostmaster.antagonist.nl. 2018052300 180 3600 1209600 86400
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 43200 IN NSEC3 1 0 1 AB D04COHDERT50P43FHSP1N5F7LDVTORH7 A AAAA RRSIG
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 43200 IN NSEC3 1 0 1 AB IDTV8EDH9FRO5UU2OC4N3PUM51SRLDGH A RRSIG
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 43200 IN NSEC3 1 0 1 AB GFL0IAO83UJDAA6IHCTHFGL6T4KNILQO A RRSIG
    antagonist.nl.          180     IN      RRSIG   SOA 13 2 180 20191205000000 20191114000000 47684 antagonist.nl. TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. 5KPt3wExlfKg4tZJ1fdR1xhnj8x8DsmgYR2+pCHkcc041thw3E6jQCfY CESVytcQcp6Zb/uJ3zxNXExJkEzZoQ==
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. Wrzps6dY9zhq14kBiFp0KwDqdkMtceOMV2cMKPkznhxFcsmpsTazZX1Z MAw/565cRwpWRoU5LuGNzGHg3ZstUQ==
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. DBJvz7HbYSFS/PHtTXD2qMwsKuWXoqNj8MPNMIk84Jv4kY1w52EevWIS nIgDknp9DbzYcczQzOOu1cyEYulYPg==

The TTLs are remarkably unchanging at:

    * 180s SOA and RRSIG TTL == origin TTL
    * 12H NSEC3 TTL == 0.5 origin TTL
    * 24H RRSIG NSEC3 TTL == origin TTL

So either I'm getting uncached data, or something more interesting is
happening.  It feels like some nodes at Quad9 are caching NSEC3 responses for
the full RRSIG validity, and then generating responses with TTLs based on
capped by the origin TTL and/or a local limit.

Using the signature inception/expiration interval as a cache interval, rather
the provided TTL (if that's what this is) is not expected or I believe valid.

-- 
    Viktor.

From woody at pch.net  Tue Nov 26 15:09:51 2019
From: woody at pch.net (Bill Woodcock)
Date: Tue, 26 Nov 2019 16:09:51 +0100
Subject: [dns-operations] Quad9 denial of existence for
 _25._tcp.mx1.p01.antagonist.nl IN TLSA
In-Reply-To: <mailman.1116.1574779381.1398.dns-operations@lists.dns-oarc.net>
References: <20191126042751.GD34850@straasha.imrryr.org>
 <mailman.1116.1574779381.1398.dns-operations@lists.dns-oarc.net>
Message-ID: <5D54C809-3F42-49A0-BA55-C6C995140DDC@pch.net>

Also I?ve forwarded this thread to the Quad9 operations team to look at.

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191126/bd13e7fa/attachment.sig>

From muks at mukund.org  Tue Nov 26 15:51:06 2019
From: muks at mukund.org (Mukund Sivaraman)
Date: Tue, 26 Nov 2019 21:21:06 +0530
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
Message-ID: <20191126154932.GA16734@jurassic.lan.banu.com>

On Tue, Nov 26, 2019 at 08:41:51AM -0500, Mark Allman wrote:
> 
> Let me try to get away from what is or is not "big" and ask two
> questions.  (These are legit questions to me.  I have studied the
> DNS a whole bunch, but I do not operate any non-trivial part of the
> DNS and so that viewpoint is valuable to me.)
> 
> (1) Setting aside history and how things have been done and why
>     (which I am happy to stipulate is rational)... At this point,
>     are there tangible benefits for getting information about the
>     TLD nameservers to resolvers as needed via a network service?
> 
> (2) Are there fundamental problems that would arise in recursive
>     resolvers if the information about TLD nameservers was no longer
>     available via a network service, but instead had to come from a
>     file that was snarfed periodically?

Probably not many. There are some Twitter feeds about what kinds of
changes occur to the root zone and how frequently, e.g.:

https://twitter.com/diffroot

I like how you've posed your questions, at a high-level view.

In the past few years, I've heard of several proposals for improving
root zone resilience, and how it can be made available to resolvers more
readily and robustly.

* RFC 7706 (root zone on loopback)
* Paul Vixie's idea about making one of the root letters have AS112
  style IP addresses
* Root zone mirroring with zone transfer over HTTPS
* Root zone distribution via bittorrent (IIRC I heard it from NLnet Labs
  staff)
* Root zone distribution as a blockchain
* DNS as a blockchain
* Combining zones into a look-aside megazone that is well provisioned

The root zone is another zone. Due to real-world traffic patterns, it is
perhaps more resilient to authoritative service degradation than
top-level zones such as "com." because once a TLD delegation (e.g.,
com.) is cached in a resolver, it is not going to look in the root zone,
when names in the TLD (e.g., com.) are queried, for a very long time.

DNS will always have an under-provisioning problem until there is some
policy about traffic. It will be so as long as a network-connected IP
camera is able to generate packets that saturate its 1Gbps link, and as
long as manufacturers are not liable for how their devices behave
(quality of firmware, updates, etc.).

Resilience applies to _any_ zone, not just the root zone. If an
Alexa-top-10 example.com company's authoritative DNS nameservers are
attacked by an equivalent of the Mirai botnet, or worse, a government
sponsored packet flood / DNS QUERY flood, overprovisioning to handle
such attacks increases its running costs by orders of magnitude. CDNs
with their global anycast DNS service are popular these days, but their
resiliency would depend on the specific attack circumstances. Not a year
goes by where we don't hear of a significant DNS outage due to a
DDoS. Use of such CDNs have also made DNS more centralized, which not
everybody thinks is wise for the general health of the internet.
Availability of a service doesn't depend just on resilience to DDoS
attacks.

If we use response/query percentage (response rate) as a metric for
service quality of a zone, a popular TLD zone would be more vulnerable
than the root when there is similar degradation of response rate.  The
same can be said for CDN-style global anycast authoritiative
DNS too. What would be more noticed and make the popular news - if
root-servers were to drop to 50% of their reply rate, or if Cloudflare
DNS were to drop to 50% of its reply rate?

It does not appear taking over-provisioning for granted would work
well. Borrowing a sibling reply's nomenclature, "large" will not work
robustly now or in the long term. "Clever" has to be better than root on
loopback - it has to work for other parts of DNS too (what if the root
works, but we can't resolve any new queries in the "com." TLDs?)
"Clever" has to be also about regulating, about limits imposed in
equipment by laws, and responsibility for maintaining connected
devices. The average human who installs a security camera knows nothing
about what happens on the wire and cannot realistically be expected to
be responsible.

		Mukund

From ietf-dane at dukhovni.org  Tue Nov 26 16:04:33 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 26 Nov 2019 11:04:33 -0500
Subject: [dns-operations] Quad9 denial of existence for
 _25._tcp.mx1.p01.antagonist.nl IN TLSA
In-Reply-To: <20191126150938.GF34850@straasha.imrryr.org>
References: <20191126042751.GD34850@straasha.imrryr.org>
 <b6e68d8d-e1b3-08ef-c7fd-ec8b39f2c9dd@reening.net>
 <20191126150938.GF34850@straasha.imrryr.org>
Message-ID: <20191126160433.GG34850@straasha.imrryr.org>

On Tue, Nov 26, 2019 at 10:09:38AM -0500, Viktor Dukhovni wrote:

> Yes, I still the DoE response from 9.9.9.10, and also (not always) from
> its peer 149.112.112.10:

Though I've never succeeded in eliciting an NXDOMAIN for this qname from the
authoritative servers, I just observed a DoE also from Cloudflare, from both
1.0.0.1 and 1.1.1.1:

    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11156
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 1452
    ;; AUTHORITY SECTION:
    antagonist.nl.          180     IN      SOA     ns1.antagonist.nl. hostmaster.antagonist.nl. 2018052300 180 3600 1209600 86400
    antagonist.nl.          180     IN      RRSIG   SOA 13 2 180 20191205000000 20191114000000 47684 antagonist.nl. TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN NSEC3 1 0 1 AB D04COHDERT50P43FHSP1N5F7LDVTORH7 A AAAA RRSIG
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. 5KPt3wExlfKg4tZJ1fdR1xhnj8x8DsmgYR2+pCHkcc041thw3E6jQCfY CESVytcQcp6Zb/uJ3zxNXExJkEzZoQ==
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN NSEC3 1 0 1 AB IDTV8EDH9FRO5UU2OC4N3PUM51SRLDGH A RRSIG
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. Wrzps6dY9zhq14kBiFp0KwDqdkMtceOMV2cMKPkznhxFcsmpsTazZX1Z MAw/565cRwpWRoU5LuGNzGHg3ZstUQ==
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN NSEC3 1 0 1 AB GFL0IAO83UJDAA6IHCTHFGL6T4KNILQO A RRSIG
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. DBJvz7HbYSFS/PHtTXD2qMwsKuWXoqNj8MPNMIk84Jv4kY1w52EevWIS nIgDknp9DbzYcczQzOOu1cyEYulYPg==

Once again, oddly the TTL don't change when I ask again, but I may not be hitting
the same cache.

Never yet from Google or Verisign, but perhaps the issue is upstream, and Quad9 has
just been less lucky than the others recently.

-- 
    Viktor.

From jtk at depaul.edu  Tue Nov 26 16:30:34 2019
From: jtk at depaul.edu (John Kristoff)
Date: Tue, 26 Nov 2019 10:30:34 -0600
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <189e64e1818d4db1bb8fd75ad02c83a5@ex16prd04a.dpu.depaul.edu>
References: <189e64e1818d4db1bb8fd75ad02c83a5@ex16prd04a.dpu.depaul.edu>
Message-ID: <20191126103034.16eb09df@p50.localdomain>

On Mon, 25 Nov 2019 20:30:32 +0000
Mark Allman <mallman at icir.org> wrote:

> Left here to be ripped apart ... :-)

Hello Mark,

Without making any explicit remarks on your paper or on the following,
in case you missed it, I remembered I had seen something like this
proposed before:

  Domain Name System Without Root Servers
  Matth?us Wander, Christopher Boelmann, Torben Weis
  <https://link.springer.com/chapter/10.1007/978-3-319-76687-4_14>

John


From list-dns-operations at dragon.net  Tue Nov 26 17:46:57 2019
From: list-dns-operations at dragon.net (Paul Ebersman)
Date: Tue, 26 Nov 2019 09:46:57 -0800
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <0CE95B73-B4DF-45B9-92FF-66C85695BA84@rfc1035.com>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <20191125223149.B3EE019AD672@fafnir.remote.dragon.net>
 <0CE95B73-B4DF-45B9-92FF-66C85695BA84@rfc1035.com>
Message-ID: <20191126174657.871EF19B0633@fafnir.remote.dragon.net>

ebersman> Actually, it's a great argument for longer TTLs and caching
ebersman> doing what they're supposed to.

jim> It would be if the root only got queries from well behaved
jim> recursive resolvers. But we both know Paul that simply isn't true.

jim> Well over 90% of the query traffic at the root has no reason to be
jim> going there at all. For instance stub resolvers that don't care
jim> about TTLs or do any sort of caching, Chrome's 10-character nonce
jim> strings to detect NXDOMAIN rewriting, CPE querying for .home,
jim> enterprises leaking queries for .corp, etc, etc.

You cut off the last line of my post:

ebersman> But compared to a large corp DNS server farm, the root servers
ebersman> shovel a lot of bits. Some of it even valid DNS queries and
ebersman> responses. ;)

Yes. Most of it is crap and the normal DNS rules don't apply. But TTLs
and caching do help (less with root than TLD due to garbage problem) and
the orders of magnitude differences in size of traffic between root/TLD
and large recursive farms is still valid.

We started this with "what's a lot of traffic" and I think you and I
would agree defining "lots" is very dependent on what DNS role you play.

And we've both been around long enough to agree that even if well
behaved and well designed DNS start shifting to local root and similar,
there's enough just crap and enough legacy/old folks needing traditional
root that we're going to be upgrading the traditional root architecture
for a long long time.

But every bit helps, so local root, saner TTLs, solid caching layer are
all still worth building as well.

From list-dns-operations at dragon.net  Tue Nov 26 17:56:53 2019
From: list-dns-operations at dragon.net (Paul Ebersman)
Date: Tue, 26 Nov 2019 09:56:53 -0800
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
Message-ID: <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>

mallman> Setting aside history and how things have been done and why
mallman> (which I am happy to stipulate is rational)... At this point,
mallman> are there tangible benefits for getting information about the
mallman> TLD nameservers to resolvers as needed via a network service?

The biggest problem I see here is the legacy/long-tail problem. As of a
few years ago, I bumped into BIND 4 servers still active. Wouldn't be
shocked to hear they are still being used.

IPv4 reachable traditional DNS servers for some tiny group of antique
folks will be needed for years, even if we get 99+% of the world to some
new system.

Doesn't mean we shouldn't be thinking about a better way to do it for
that 99% though.

mallman> Are there fundamental problems that would arise in recursive
mallman> resolvers if the information about TLD nameservers was no
mallman> longer available via a network service, but instead had to come
mallman> from a file that was snarfed periodically?

/etc/hosts.txt via bittorrent instead of ftp from sri-nic? :)

The DNS is only billed as loosely coherent, so conceptually this could
work. But I'd have to be convinced it was enough better in terms of data
integrity, coherence and availability than the current DNS/DNSSEC to be
worth the pain of changing that much code on all those devices/servers.

From dot at dotat.at  Tue Nov 26 20:58:06 2019
From: dot at dotat.at (Tony Finch)
Date: Tue, 26 Nov 2019 20:58:06 +0000
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <20191126154932.GA16734@jurassic.lan.banu.com>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126154932.GA16734@jurassic.lan.banu.com>
Message-ID: <alpine.DEB.2.20.1911262040430.17186@grey.csi.cam.ac.uk>


I generally agree with Geoff Huston's thoughts on this subject
http://www.potaroo.net/ispcol/2019-04/root.html

Mirror zones (validated zone transfers) fall on the wrong side of the
cost/benefit equation for me. But I might change my mind if there were
better security for unauthenticated records (NS and glue), e.g.

* xfer-over-TLS - I'm really looking forward to support for authenticated
  server / anonymous client for zone transfers: nice for local root zones
  and cross-campus zone distribution.

* zone digests - interesting for end-to-end verification but maybe too
  complicated?


Mukund Sivaraman <muks at mukund.org> wrote:
>
> There are some Twitter feeds about what kinds of
> changes occur to the root zone and how frequently, e.g.:
>
> https://twitter.com/diffroot

Note that @diffroot does not tweet about changes to glue addresses which
happen a lot more frequently than NS and DS changes.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Biscay: Southwest, veering west, 6 to gale 8, occasionally severe gale 9 until
later. Rough or very rough becoming very rough or high, becoming very rough
later. Thundery showers. Good, occasionally poor.

From mallman at icir.org  Wed Nov 27 00:40:24 2019
From: mallman at icir.org (Mark Allman)
Date: Tue, 26 Nov 2019 19:40:24 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>
Message-ID: <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>


Hi Paul!

> The biggest problem I see here is the legacy/long-tail problem. As
> of a few years ago, I bumped into BIND 4 servers still
> active. Wouldn't be shocked to hear they are still being used.
>
> IPv4 reachable traditional DNS servers for some tiny group of
> antique folks will be needed for years, even if we get 99+% of the
> world to some new system.

I wonder if we're ever allowed to just decide this sort of thing is
ridiculous old shit and for lots of reasons we can and should just
garbage collect it away.

> Doesn't mean we shouldn't be thinking about a better way to do it
> for that 99% though.

Is it better if we only get to 99%?

To me, this whole notion is that we can in fact get rid of this
giant network service.  If we don't get rid of it then what is the
incentive to move one's own resolver away from using the root
nameservers?  I don't have any heartburn with RFC 7706.  But, it is
a quite minor optimization in the general case.  It may well be
important in some corner cases, but in general I don't think running
a local root nameserver helps all that much.

Maybe 99% lets us draw down the size of the root infrastructure...I
dunno.  But, if we don't say something like "it's going to go away"
then I am not sure resolvers will move away from it.

allman


--
https://www.icir.org/mallman/
@mallman_icsi

From list-dns-operations at dragon.net  Wed Nov 27 03:18:02 2019
From: list-dns-operations at dragon.net (Paul Ebersman)
Date: Tue, 26 Nov 2019 19:18:02 -0800
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>
 <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
Message-ID: <20191127031802.4CB6419B63FD@fafnir.remote.dragon.net>

ebersman> IPv4 reachable traditional DNS servers for some tiny group of
ebersman> antique folks will be needed for years, even if we get 99+% of
ebersman> the world to some new system.

mallman> I wonder if we're ever allowed to just decide this sort of
mallman> thing is ridiculous old shit and for lots of reasons we can and
mallman> should just garbage collect it away.

We aren't allowed as IETF/engineers. The world sort of is. ;)

Eventually, someone wonders why they're burning money on something they
don't see a need for any more.

Sadly, based on the number of IBM AS400s in service, the COBOL programs
with no source still being used, SNA, X.25 and all sorts of other stuff
that you'd think would have been dead decades ago, I'm not betting on
this happening any time soon.

mallman> To me, this whole notion is that we can in fact get rid of this
mallman> giant network service.  If we don't get rid of it then what is
mallman> the incentive to move one's own resolver away from using the
mallman> root nameservers?

But what would we replace it with? Who would run it? How would we get
uniqueness, data integrity, high availability, decent coherence? How
would we get something the entire world would use?

Part of why DNS is so abused and misused is that it's already here and
it mostly scales/works. We did it before the world knew about the
internet. Now there's way more attention, money, and politics that get
in the way of truly massive changes. If DNS started from scratch today,
it's not clear it would happen.

Not saying it's impossible but it will be a daunting task and will have
to be really really compelling (or be the next user loved
shiny-ball/Pokemon). Look at how much fun and progress there is moving
from IPv4 to IPv6.

mallman> Maybe 99% lets us draw down the size of the root
mallman> infrastructure...I dunno.  But, if we don't say something like
mallman> "it's going to go away" then I am not sure resolvers will move
mallman> away from it.

The problem/load isn't the folks that would upgrade. It's crap broken
code/devices that are in many cases forgotten in closets or under
desks. The magic blue smoke will have to pour out the back before they
stop sending useless crap to the root servers.

A6 records were never officially "blessed". We went with AAAA. We were
all pretty sure they would never be used. But last I heard, the root
servers still see A6 queries. Google for Geoff Huston's zombie DNS preso
for more scary/bad stories.

Love to see your proposal for a replacement. Just be prepared to have to
support whatever that is and DNS both for a very long time.

From ggm at algebras.org  Wed Nov 27 03:36:19 2019
From: ggm at algebras.org (George Michaelson)
Date: Wed, 27 Nov 2019 13:36:19 +1000
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>
 <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
Message-ID: <CAKr6gn2YCOKYsrhC_id3gC9jCTQfQFeXCQ535QbCKVmwQrL8vA@mail.gmail.com>

I tend to functional questions in these matters. This is not a
symmetric pair, but they go to different sides of the problem

1) what will happen if we imagine these queries not being answered? A
hypothetical (*and, its not zero cost*) front-end process which drops
them

2) what is the consequence of continuing to answer these queries?

Noting 1) is not trivial, I believe if these queries were not
answered, there would be short-term downsides, but long-term upsides.
The problem would (I believe) go away.

Noting 2) is the "do nothing" option. The only clear consequence is
that we're incurring cost, in root instantiations. It is possible if
we go with run-root-on-local/loopback we smear the cost, but do we
reduce it?

-G

On Wed, Nov 27, 2019 at 1:00 PM Mark Allman <mallman at icir.org> wrote:
>
>
> Hi Paul!
>
> > The biggest problem I see here is the legacy/long-tail problem. As
> > of a few years ago, I bumped into BIND 4 servers still
> > active. Wouldn't be shocked to hear they are still being used.
> >
> > IPv4 reachable traditional DNS servers for some tiny group of
> > antique folks will be needed for years, even if we get 99+% of the
> > world to some new system.
>
> I wonder if we're ever allowed to just decide this sort of thing is
> ridiculous old shit and for lots of reasons we can and should just
> garbage collect it away.
>
> > Doesn't mean we shouldn't be thinking about a better way to do it
> > for that 99% though.
>
> Is it better if we only get to 99%?
>
> To me, this whole notion is that we can in fact get rid of this
> giant network service.  If we don't get rid of it then what is the
> incentive to move one's own resolver away from using the root
> nameservers?  I don't have any heartburn with RFC 7706.  But, it is
> a quite minor optimization in the general case.  It may well be
> important in some corner cases, but in general I don't think running
> a local root nameserver helps all that much.
>
> Maybe 99% lets us draw down the size of the root infrastructure...I
> dunno.  But, if we don't say something like "it's going to go away"
> then I am not sure resolvers will move away from it.
>
> allman
>
>
> --
> https://www.icir.org/mallman/
> @mallman_icsi
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

From ondrej at sury.org  Wed Nov 27 08:53:54 2019
From: ondrej at sury.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Wed, 27 Nov 2019 09:53:54 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
Message-ID: <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>

Mark,

I believe that any distributed system that won?t have a fallback to the RZ
is inevitably doomed and will get out of sync.

The RFC7706 works because there?s always a safe guard and if the resolver
is unable to use mirrored zone, it will go to the origin.

Call me a pessimist, but I?ve yet to see a loosely often neglected distributed system
that won?t get out of sync.

So, while the idea of distributing the full RZ to every resolver out there, there are two
fundamental problems:

1. resilience - both against DoS and just plain breakage
2. the old clients - while the situation out there is getting better, we will still be stuck with
    old codebase for foreseeable future

What we can do is to make the load on RZ servers lighter, but we can?t make them just go.

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



> On 26 Nov 2019, at 14:41, Mark Allman <mallman at icir.org> wrote:
> 
> 
> Let me try to get away from what is or is not "big" and ask two
> questions.  (These are legit questions to me.  I have studied the
> DNS a whole bunch, but I do not operate any non-trivial part of the
> DNS and so that viewpoint is valuable to me.)
> 
> (1) Setting aside history and how things have been done and why
>    (which I am happy to stipulate is rational)... At this point,
>    are there tangible benefits for getting information about the
>    TLD nameservers to resolvers as needed via a network service?
> 
> (2) Are there fundamental problems that would arise in recursive
>    resolvers if the information about TLD nameservers was no longer
>    available via a network service, but instead had to come from a
>    file that was snarfed periodically?
> 
> Thanks!
> 
> allman
> 
> 
> --
> https://www.icir.org/mallman/
> @mallman_icsi
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



From petr.spacek at nic.cz  Wed Nov 27 15:31:51 2019
From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=)
Date: Wed, 27 Nov 2019 16:31:51 +0100
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <FD9E58CF-1171-4209-B927-A7097E862D36@dnss.ec>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
 <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
 <FD9E58CF-1171-4209-B927-A7097E862D36@dnss.ec>
Message-ID: <5db0b8e9-b460-a650-2b76-cd23f6561167@nic.cz>

On 26. 11. 19 16:04, Roy Arends wrote:
> 
> 
>> On 26 Nov 2019, at 12:46, David Conrad <drc at virtualized.org> wrote:
>>
>> It would appear a rather large percentage of queries to the root (like 50% in some samples) are random strings, between 7 to 15 characters long, sometimes longer.  I believe this is Chrome-style probing to determine if there is NXDOMAIN redirection. A good example of the tragedy of the commons, like water pollution and climate change.
> 
> Yep.
> 
> https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3/chrome/browser/intranet_redirect_detector.cc
> Line 79: "// We generate a random hostname with between 7 and 15 characters.?
> 
> https://ithi.research.icann.org/graph-m3.html
> Table "Queries to frequently found name patterns? shows that the frequency distribution for queries between 7 and 15 characters are near flat (around 5.2% per character length) AND an order higher than ANY other queries.
> 
> ?Coincidence? I think NOT!?  
> 
> https://youtu.be/MDpuTqBI0RM?t=53

FYI there is also an issue about this in their tracker:
https://bugs.chromium.org/p/chromium/issues/detail?id=946450#c1

-- 
Petr ?pa?ek  @  CZ.NIC

From keith at dns-oarc.net  Wed Nov 27 15:38:32 2019
From: keith at dns-oarc.net (Keith Mitchell)
Date: Wed, 27 Nov 2019 10:38:32 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>
 <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
Message-ID: <c78523b7-812b-604f-6b3d-abb9939a9882@dns-oarc.net>

On 11/26/19 7:40 PM, Mark Allman wrote:
> I wonder if we're ever allowed to just decide this sort of thing is 
> ridiculous old shit and for lots of reasons we can and should just 
> garbage collect it away.

To some extent, "get rid of ridiculous old sh*t" is kind of what the DNS
Flag Days are working on, though with rather more baby steps than I
suspect you are conceiving. Even these small, rational proposals have
met with push-back in some sectors. It's quite a lot of work to
deprecate stuff in a way that minimizes operational fall-out.

> To me, this whole notion is that we can in fact get rid of this
> giant network service.  If we don't get rid of it then what is the 
> incentive to move one's own resolver away from using the root 
> nameservers?

On garbage-collecting crap traffic, it's worth looking at AS112. Mostly
this runs on a bottom-up community-driven basis, where the incentive to
run an AS112 node comes from the simple self-interested economic basis
of not wanting this crap taking up capacity on one's own outbound
infrastructure.

While AS112 makes a difference, it is far from ubiquitous or optimal.
Probably there are gains to be made from more aggressive co-ordination
and advocacy (*), but I suspect these would need stronger resource
support from a more top-down source. It's far from the whole problem
space, but makes some difference at the root for sure.

Keith


(*) every so often I get a stark reminder of how low awareness of AS112
is...no, we don't want to buy transit for it, thanks..

From petr.spacek at nic.cz  Wed Nov 27 15:54:48 2019
From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=)
Date: Wed, 27 Nov 2019 16:54:48 +0100
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
Message-ID: <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>

On 27. 11. 19 9:53, Ond?ej Sur? wrote:
> Mark,
> 
> I believe that any distributed system that won?t have a fallback to the RZ
> is inevitably doomed and will get out of sync.
> 
> The RFC7706 works because there?s always a safe guard and if the resolver
> is unable to use mirrored zone, it will go to the origin.
> 
> Call me a pessimist, but I?ve yet to see a loosely often neglected distributed system
> that won?t get out of sync.
> 
> So, while the idea of distributing the full RZ to every resolver out there, there are two
> fundamental problems:
> 
> 1. resilience - both against DoS and just plain breakage
> 2. the old clients - while the situation out there is getting better, we will still be stuck with
>     old codebase for foreseeable future
> 
> What we can do is to make the load on RZ servers lighter, but we can?t make them just go.

I think there is even more fundamental problem:
Someone has to pay operational costs of "the new system".

Personally I do not see how transition to another root-zone-distribution system solves the over-provisioning problem - the new system still has to be ready to absorm absurdly large DDoS attacks.

Example:
Have a look at https://www.knot-dns.cz/benchmark/ . The numbers in charts at bottom of the page show that a *single server machine* is able to reply *all* steady state queries for the root today.

Sure, we have speed-of-light limits, so let's say we need couple hunderd servers in well connected places to keep reasonable latency. That's not a huge cost overall (keep in mind that these local nodes could be pretty small *if we were ignoring the over-provisioning problem*).

Most of the money is today spent on *massive* over-provisioning. As an practical example, CZ TLD is over-provisiong factor is in order of *hunderds* of stead-state query traffic, and the root might have even more.

Once we have similarly resilient HTTP system it is matter of simple configuration :-D
https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling

-- 
Petr ?pa?ek  @  CZ.NIC

From petr.spacek at nic.cz  Wed Nov 27 16:18:02 2019
From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=)
Date: Wed, 27 Nov 2019 17:18:02 +0100
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
 <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
Message-ID: <802e6930-5883-6b6d-2968-38efb65d4903@nic.cz>

On 26. 11. 19 12:46, David Conrad wrote:
> On Nov 26, 2019, at 11:33 AM, Jim Reid <jim at rfc1035.com <mailto:jim at rfc1035.com>> wrote:
>>> On 26 Nov 2019, at 09:16, Florian Weimer <fw at deneb.enyo.de <mailto:fw at deneb.enyo.de>> wrote:
>>>
>>> Up until recently, well-behaved recursive resolvers had to forward
>>> queries to the root if they were not already covered by a delegation.
>>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>>> was just how the protocol was expected to work.
>>
>> So what? These RFCs make very little difference to the volume of queries a resolving server will send to the root. QNAME minimisation has no impact at all: the root just sees a query for .com instead of?foobar.com <http://foobar.com/>. A recursive resolver should already be supporting negative caching and will have a reasonably complete picture of what's in (or not in) the root. RFC8198 will of course help that but not by much IMO.
> 
> It would appear a rather large percentage of queries to the root (like 50% in some samples) are random strings, between 7 to 15 characters long, sometimes longer. ?I believe this is Chrome-style probing to determine if there is NXDOMAIN redirection. A good example of the tragedy of the commons, like water pollution and climate change.
> 
> If resolvers would enable DNSSEC validation, there would, in theory, be a reduction in these queries due to aggressive NSEC caching. ?Of course, practice may not match theory (https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf). 

The discussion after the talk (including hallway :-) was also interesting, and with all respect for Geoff's work, these slides should be read with some sceptism.

Main points:
1) Load-balancer with N resolver nodes behind it decrease effectivity of aggressive cache by factor N, it *does not* invalidate the concept.

In other words, a random subdomain attack which flows through resolver farm with N nodes has to fill N caches with NSEC records, and that will simply take N times longer when compared with non-load-balanced scenario.

The aggressive cache still provides upper bound for size of NXDOMAIN RRs in cache, which is super useful under attack because it prevents individual resolvers from dropping all the useful content from cache during the attack.


2) Two out of five major DNS resolver implementations used by large ISPs did not implement aggressive caching (yet?), so it needs to be expected that deployment is not great. Also the feature is pretty new and large ISPs are super conservative and might not deployed new versions yet ...

I forgot the rest so I will conclude with: Watch the video recording and think yourself! :-)
Petr ?pa?ek  @  CZ.NIC


> 
> Of course, steady state query load is largely irrelevant since root service has to be provisioned with massive DDoS in mind. In my personal view, the deployment of additional anycast instances by the root server operators is a useful stopgap, but ultimately, given the rate of growth of DoS attack capacity (and assuming that growth will continue due to the stunning security practices of IoT device manufacturers), stuff like what is discussed in that paper is the right long term strategy.


From dwessels at verisign.com  Wed Nov 27 18:25:21 2019
From: dwessels at verisign.com (Wessels, Duane)
Date: Wed, 27 Nov 2019 18:25:21 +0000
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87tv6rmwef.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
Message-ID: <4BFD23E6-2208-440C-A982-57432ECD3568@verisign.com>



> On Nov 25, 2019, at 2:19 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> * Jim Reid:
> 
>>> On 25 Nov 2019, at 20:54, Florian Weimer <fw at deneb.enyo.de> wrote:
>>> Is it because of the incoming data is interesting?
>> 
>> Define interesting.
> 
> The data could have monetary value.  Passwords that are otherwise
> difficult to come by might be leaking.

Hi Florian,

I can assure you that Verisign does not monetize the root server data.  If
any other operators do, I'm not aware of it.

We do utilize root server data for research purposes from time-to-time.
Recent examples include the KSK rollover and name collisions.  Less recent
examples include understanding TTL/caching behavior and preparing for the
root ZSK size increase.  When DDoS attacks happen, we often analyze the
data to see if we can understand how and why it happened, and to be better
prepared for the next one.

DW


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4675 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191127/ae334ea1/attachment.bin>

From dwessels at verisign.com  Wed Nov 27 18:28:31 2019
From: dwessels at verisign.com (Wessels, Duane)
Date: Wed, 27 Nov 2019 18:28:31 +0000
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <330051A6-AE60-47C5-A97B-A4D305636C01@pch.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <330051A6-AE60-47C5-A97B-A4D305636C01@pch.net>
Message-ID: <32C4B657-6B3A-4E81-AD9B-8E4DA1AFDA16@verisign.com>



> On Nov 25, 2019, at 1:23 PM, Bill Woodcock <woody at pch.net> wrote:
> 
>> On Nov 25, 2019, at 9:54 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
>> The query numbers are surprisingly low.  To me at last.
> 
> Duane Wessels did a good study some time ago of queries to the root.  I believe over 99% were bogus, not real queries for resolvable things.

For the record, the number from that study (2003!) was 98%.  I believe it has since been reconfirmed to be about the same level in a number of subsequent studies by others.

DW


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4675 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191127/0cdb2feb/attachment.bin>

From m3047 at m3047.net  Wed Nov 27 18:47:10 2019
From: m3047 at m3047.net (Fred Morris)
Date: Wed, 27 Nov 2019 10:47:10 -0800 (PST)
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <5db0b8e9-b460-a650-2b76-cd23f6561167@nic.cz>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com>
 <87zhgjgfq7.fsf@mid.deneb.enyo.de>
 <5ABED0DB-8C9A-498E-82DC-532ACF7E1D45@rfc1035.com>
 <2B861917-4836-444B-A76F-294BAD24D416@virtualized.org>
 <FD9E58CF-1171-4209-B927-A7097E862D36@dnss.ec>
 <5db0b8e9-b460-a650-2b76-cd23f6561167@nic.cz>
Message-ID: <alpine.LSU.2.21.1911270929030.21883@flame.m3047>

I've been following this thread, and I'm well aware of the massive amounts 
of NXDOMAIN stuff. I don't know enough about this specific issue.

But there are things which happen in Browser Land which would lead me to 
naively conclude the people making browsers don't understand DNS. Two 
recent (actually ongoing) examples:

1) Firefox still (years now, although I haven't filed a bug) doesn't
    understand that it's perfectly ok to have a trailing dot on an FQDN;
    and it serves a purpose. (It's not supposed to be included in the TLS
    Host: header though.)

2) In spite of implementing their own DNS resolvers, browsers seem unable
    to block domains cloaked by CNAMEs (the third party trackers accessing
    first party cookies trope, RPZ works just fine for some odd reason).

On Wed, 27 Nov 2019, Petr ?pa?ek wrote:
>> [...]
>> ?Coincidence? I think NOT!? 
>> 
>> https://youtu.be/MDpuTqBI0RM?t=53
>
> FYI there is also an issue about this in their tracker:
> https://bugs.chromium.org/p/chromium/issues/detail?id=946450#c1

As I understand it these are unadorned labels, unit of one. Two 
parts to this.


What's Chrome's point with this? They've trained monkeys that URLs are for 
Boomers, just type a search string in there. Wild guess here, it goes 
something like this:

User types an undotted hostname on their network. Chrome searches and 
returns a bunch of shopping and social media sites. Ok, that makes monkeys 
upset. Well, we'll go off the reservation (we really hate doing this) and 
see if our operating environment resolves it before searching. Oh drat! 
The operating environment is doing a search! Some monkeys are upset either 
way. Prod Mgr: They're interfering with our search! They don't understand 
the one true way! Dev: I think we should agressively probe the operating 
environment with garbage, the best defense is a good offense. Prod Mgr: 
Let's call it a "friendly" probe and I'm good with it.

Fine, you may not like my personalizations, but is that it? I don't 
believe these people are idiots with no knowledge of DNS operation.

To riff off of an old South Park episode, there seems to be a lot of smug 
in the air. It's not just one thing. It's a pattern of engineering around 
the DNS. Poorly.

Since I don't use Chrome, could somebody please type a local hostname (one 
label) with a trailing dot into the thing and see what happens? Nothing 
good, I'm sure. Those who know the purpose of the trailing dot will know 
that this should outright fail to resolve (probably sends a request to the 
root for the label as a TLD).

Since they're already engineering around the DNS and the trailing dot has 
been a casualty for some time, would it be unthinkable for them to 
repurpose it as a declarative: this label needs to be sent to the 
operating environment resolver (without the dot). Search lists... 
everybody hates search lists.


Let me put it to you this way: which do you hate more, search lists or 
unary labels hitting the roots?

Shouldn't what happens be that they spew their probe at the operating 
environment resolver, it appends things from the search list and tries 
those?

If there's a shared engineering problem here, isn't it that when these 
fail, the resolver tries the naked label? Or tries it first, but in any 
case, tries it.

Isn't the proliferation of "valid" TLDs contributing to this embarrassment 
of riches by making approaches such as selectively whitelisting TLDs so 
increasingly impractical as to obviate consideration?

Should local resolvers reject attempts to resolve single labels as TLDs 
unless RD=0?


I apologize, none of this is fully baked, but the debate doesn't seem to 
be encompassing the entirety of the system.

--

Fred Morris

From drc at virtualized.org  Wed Nov 27 20:49:35 2019
From: drc at virtualized.org (David Conrad)
Date: Wed, 27 Nov 2019 12:49:35 -0800
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
Message-ID: <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>

Petr,

> I think there is even more fundamental problem:
> Someone has to pay operational costs of "the new system?.

The ?new system? is simply the existing network of resolvers, augmented to have the root zone.  As far as I can tell, the operational cost would be in (a) ensuring the resolver is upgraded to support obtaining the root zone and (b) dealing with the fetch of the root zone with some frequency.

There would be an additional cost, that of making the root zone available to myriads of resolvers, but I believe this is an easily handled issue.

> Personally I do not see how transition to another root-zone-distribution system solves the over-provisioning problem - the new system still has to be ready to absorm absurdly large DDoS attacks.

Two ways:
- greater decentralization: there are a lot more resolvers than the number of instances root server operators are likely to ever deploy. While an individual resolver might melt down, the impact would only be the end users using that resolver (and it is relatively easy for a resolver operator to add more capacity, mitigate the attacking client, etc).
- the cost of operating and upgrade the service to deal with DDoS is distributed to folks whose job it is to provide that service (namely the ISPs or other network operators that run the resolvers).  Remember that the root server operators have day jobs, some of which are not particularly related to running root service, and they are not (currently) being compensated for the costs of providing root service.

> Have a look at https://www.knot-dns.cz/benchmark/ <https://www.knot-dns.cz/benchmark/> . The numbers in charts at bottom of the page show that a *single server machine* is able to reply *all* steady state queries for the root today.
> ...
> Most of the money is today spent on *massive* over-provisioning. As an practical example, CZ TLD is over-provisiong factor is in order of *hunderds* of stead-state query traffic, and the root might have even more.


Yep. As mentioned before, steady state is largely irrelevant.

In my view, the fact that root service infrastructure funnels up to a (logical) single point is an architectural flaw that may (assuming DDoS attack capacity continues to grow at the current rate or even grows faster with crappy IoT devices) put the root DNS service at risk.  One of the advantages of putting the root zone in the resolver is that it mitigates that potential risk.

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191127/7d7e8490/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191127/7d7e8490/attachment.sig>

From fw at deneb.enyo.de  Wed Nov 27 22:08:23 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 27 Nov 2019 23:08:23 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> (Mark Allman's
 message of "Tue, 26 Nov 2019 08:41:51 -0500")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
Message-ID: <87d0ddm0q0.fsf@mid.deneb.enyo.de>

* Mark Allman:

> Let me try to get away from what is or is not "big" and ask two
> questions.  (These are legit questions to me.  I have studied the
> DNS a whole bunch, but I do not operate any non-trivial part of the
> DNS and so that viewpoint is valuable to me.)
>
> (1) Setting aside history and how things have been done and why
>     (which I am happy to stipulate is rational)... At this point,
>     are there tangible benefits for getting information about the
>     TLD nameservers to resolvers as needed via a network service?
>
> (2) Are there fundamental problems that would arise in recursive
>     resolvers if the information about TLD nameservers was no longer
>     available via a network service, but instead had to come from a
>     file that was snarfed periodically?

What's the change rate for the root zone?  If there is a full
transition of the name server addresses for a zone, how long does it
typically take from the first change to the completion of the sequence
of changes?

If the answer, ?this has never happened?, then using a fairly static
data source should probably be okay (similar to how the browser PKI is
maintained).  Due to the way DNSSEC works with its periodic renewal of
signatures, validating non-recursive resolvers will automatically
verify the freshness of the local root zone copy.  Even if there are
few such clients, I expect that for most operators, it will
effectively prevent undetected decay due to a stale root zone (where
more and more stale delegations accumulate until performance is
seriously impacted, and fresh bootstrap using external data is
needed).

The other question is whether that data source will make it harder for
ICANN or someone else to hand over control over the TLD in a
unilateral manner.  And then it's not even clear whether that's a good
thing or not.

Other uncertainties relate to the size of the root zone.  It seems
that the phase of aggressive growth is more or less over.  But
hard-coding an assumption that resolvers can load the root zone into
memory is on a different level because it limits policy basically for
forever.

I've thought a bit whether the root domain list should be pushed into
(non-validating) stub resolvers, but I don't think that's possible
because people really like to use local domains.


From jared at puck.nether.net  Wed Nov 27 23:09:29 2019
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 27 Nov 2019 18:09:29 -0500
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87d0ddm0q0.fsf@mid.deneb.enyo.de>
References: <87d0ddm0q0.fsf@mid.deneb.enyo.de>
Message-ID: <216D841C-2AB0-459E-8240-992E754E42BA@puck.nether.net>



> On Nov 27, 2019, at 5:26 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> What's the change rate for the root zone?  If there is a full
> transition of the name server addresses for a zone, how long does it
> typically take from the first change to the completion of the sequence
> of changes?

There are regular changes. 

Resolvers regularly have old data. Survey for old root hints to see how bad they are. 

From ietf-dane at dukhovni.org  Thu Nov 28 02:55:25 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 27 Nov 2019 21:55:25 -0500
Subject: [dns-operations] [Solved] (not just) Quad9 denial of existence
 for _25._tcp.mx1.p01.antagonist.nl IN TLSA
In-Reply-To: <20191126160433.GG34850@straasha.imrryr.org>
References: <20191126042751.GD34850@straasha.imrryr.org>
 <b6e68d8d-e1b3-08ef-c7fd-ec8b39f2c9dd@reening.net>
 <20191126150938.GF34850@straasha.imrryr.org>
 <20191126160433.GG34850@straasha.imrryr.org>
Message-ID: <20191128025525.GH34850@straasha.imrryr.org>

Root cause found, the antagonist.nl domain has 3 listed nameservers:

    ns1.antagonist.nl.
    ns2.antagonist.net.
    ns3.antagonist.de.

but the IP address returned by the actual antagonist.de zone:

    ns3.antagonist.de. IN A 139.162.173.192

differs from the glue record returned from the .DE zone:

    ns3.antagonist.de. IN A 66.228.42.134

And it is this 66.228.42.134 (returned in the .DE glue) nameserver that is
serving freshly signed denial of existence for _tcp.mx1.p01.antagonist.nl.

-- 
    Viktor.

From postmaster at wsly.de  Thu Nov 28 03:45:01 2019
From: postmaster at wsly.de (Wesley Peng)
Date: Thu, 28 Nov 2019 11:45:01 +0800
Subject: [dns-operations] Questions on private nameservers registration
In-Reply-To: <fad7245e-7f9f-d90c-2f08-c776e75ec05b@wsly.de>
References: <38789521-8b38-03ea-b818-0cc9c8019b62@wsly.de>
 <36d36e82-05d9-9344-b8ad-ee05c02d1083@saltant.com>
 <fad7245e-7f9f-d90c-2f08-c776e75ec05b@wsly.de>
Message-ID: <f395a533-18a6-0326-ad8e-363c24ee5b02@wsly.de>

Another more question, can I put DE glues into other domain registry's 
zone? For example, the COM's.

Regards.

on 2019/11/26 9:41, Wesley Peng wrote:
> John,
> 
> on 2019/11/26 9:35, John W. O'Brien wrote:
>> Are ns{1,2}.wsly.de authoritative for wsly.de? Then glue is required in
>> DE. Otherwise probably not [0].
> 
> Yes I plan to setup ns{1,2}.wsly.de to be wsly.de's auth-nameservers.
> Thank you for pointing out that.
> 
> Regards.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

From fw at deneb.enyo.de  Thu Nov 28 06:39:29 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 28 Nov 2019 07:39:29 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <216D841C-2AB0-459E-8240-992E754E42BA@puck.nether.net> (Jared
 Mauch's message of "Wed, 27 Nov 2019 18:09:29 -0500")
References: <87d0ddm0q0.fsf@mid.deneb.enyo.de>
 <216D841C-2AB0-459E-8240-992E754E42BA@puck.nether.net>
Message-ID: <87imn4bj32.fsf@mid.deneb.enyo.de>

* Jared Mauch:

>> On Nov 27, 2019, at 5:26 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> What's the change rate for the root zone?  If there is a full
>> transition of the name server addresses for a zone, how long does it
>> typically take from the first change to the completion of the sequence
>> of changes?
>
> There are regular changes. 

But does anyone swap out the name servers for a TLD over the course of
five days?

From ondrej at sury.org  Thu Nov 28 07:06:02 2019
From: ondrej at sury.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Thu, 28 Nov 2019 08:06:02 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87d0ddm0q0.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <87d0ddm0q0.fsf@mid.deneb.enyo.de>
Message-ID: <7755732B-FB8D-44C5-B724-4FFB841BD285@sury.org>


> On 27 Nov 2019, at 23:08, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> What's the change rate for the root zone?

https://twitter.com/diffroot

O.
--
Ond?ej Sur?
ondrej at sury.org



From fw at deneb.enyo.de  Thu Nov 28 07:09:06 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 28 Nov 2019 08:09:06 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <7755732B-FB8D-44C5-B724-4FFB841BD285@sury.org>
 (=?utf-8?Q?=22Ond=C5=99ej_Sur=C3=BD=22's?=
 message of "Thu, 28 Nov 2019 08:06:02 +0100")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <87d0ddm0q0.fsf@mid.deneb.enyo.de>
 <7755732B-FB8D-44C5-B724-4FFB841BD285@sury.org>
Message-ID: <87fti8a359.fsf@mid.deneb.enyo.de>

* Ond?ej Sur?:

>> On 27 Nov 2019, at 23:08, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> What's the change rate for the root zone?
>
> https://twitter.com/diffroot

Selective quoting does not help to further the discussion.  Raw change
rates do not tell us if zones keep at least of some of their servers
at constant addresses over really, really long periods of time.


From ondrej at sury.org  Thu Nov 28 07:18:16 2019
From: ondrej at sury.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Thu, 28 Nov 2019 08:18:16 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87fti8a359.fsf@mid.deneb.enyo.de>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <87d0ddm0q0.fsf@mid.deneb.enyo.de>
 <7755732B-FB8D-44C5-B724-4FFB841BD285@sury.org>
 <87fti8a359.fsf@mid.deneb.enyo.de>
Message-ID: <6372BE2B-29BF-479C-8234-DAD791722C41@sury.org>


> On 28 Nov 2019, at 08:09, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> * Ond?ej Sur?:
> 
>>> On 27 Nov 2019, at 23:08, Florian Weimer <fw at deneb.enyo.de> wrote:
>>> * Mark Allman:
>>> 
>>>> Let me try to get away from what is or is not "big" and ask two
>>>> questions.  (These are legit questions to me.  I have studied the
>>>> DNS a whole bunch, but I do not operate any non-trivial part of the
>>>> DNS and so that viewpoint is valuable to me.)
>>>> 
>>>> (1) Setting aside history and how things have been done and why
>>>>    (which I am happy to stipulate is rational)... At this point,
>>>>    are there tangible benefits for getting information about the
>>>>    TLD nameservers to resolvers as needed via a network service?
>>>> 
>>>> (2) Are there fundamental problems that would arise in recursive
>>>>    resolvers if the information about TLD nameservers was no longer
>>>>    available via a network service, but instead had to come from a
>>>>    file that was snarfed periodically?
>>> 
>>> What's the change rate for the root zone?
>> 
>> https://twitter.com/diffroot
> 
> Selective quoting does not help to further the discussion.

Including cruft also does not help to further the discussion, but fair enough, I reinstated
the rest of your email into the reply.

> Raw change
> rates do not tell us if zones keep at least of some of their servers
> at constant addresses over really, really long periods of time.

.bank
- deleted NS {ac1|ac2}.nstld.com. and added NS {a|b|c}.nic.bank. on November 20
and
- deleted NS {ac3|ac4}.nstld.com. and added NS {d|e|f}.nic.bank. on November 23

Does that answer your question?

That doesn?t include changes to GLUE records which are equally as important, so the
only value you can work with and rely on is the TTL. (172800 - 48h).

The TTL on DS is 1 day and is even more important to get the updated DS early
when there?s a breach and DS needs to be swapped as early as possible.

>> If there is a full
>> transition of the name server addresses for a zone, how long does it
>> typically take from the first change to the completion of the sequence
>> of changes?
>> 
>> If the answer, ?this has never happened?, then using a fairly static
>> data source should probably be okay (similar to how the browser PKI is
>> maintained).  Due to the way DNSSEC works with its periodic renewal of
>> signatures, validating non-recursive resolvers will automatically
>> verify the freshness of the local root zone copy.  Even if there are
>> few such clients, I expect that for most operators, it will
>> effectively prevent undetected decay due to a stale root zone (where
>> more and more stale delegations accumulate until performance is
>> seriously impacted, and fresh bootstrap using external data is
>> needed).
>> 
>> The other question is whether that data source will make it harder for
>> ICANN or someone else to hand over control over the TLD in a
>> unilateral manner.  And then it's not even clear whether that's a good
>> thing or not.
>> 
>> Other uncertainties relate to the size of the root zone.  It seems
>> that the phase of aggressive growth is more or less over.  But
>> hard-coding an assumption that resolvers can load the root zone into
>> memory is on a different level because it limits policy basically for
>> forever.
>> 
>> I've thought a bit whether the root domain list should be pushed into
>> (non-validating) stub resolvers, but I don't think that's possible
>> because people really like to use local domains.


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



From fw at deneb.enyo.de  Thu Nov 28 08:32:28 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 28 Nov 2019 09:32:28 +0100
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <6372BE2B-29BF-479C-8234-DAD791722C41@sury.org>
 (=?utf-8?Q?=22Ond=C5=99ej_Sur=C3=BD=22's?=
 message of "Thu, 28 Nov 2019 08:18:16 +0100")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <87d0ddm0q0.fsf@mid.deneb.enyo.de>
 <7755732B-FB8D-44C5-B724-4FFB841BD285@sury.org>
 <87fti8a359.fsf@mid.deneb.enyo.de>
 <6372BE2B-29BF-479C-8234-DAD791722C41@sury.org>
Message-ID: <877e3k9zab.fsf@mid.deneb.enyo.de>

* Ond?ej Sur?:

>> Raw change rates do not tell us if zones keep at least of some of
>> their servers at constant addresses over really, really long
>> periods of time.
>
> .bank
> - deleted NS {ac1|ac2}.nstld.com. and added NS {a|b|c}.nic.bank. on November 20
> and
> - deleted NS {ac3|ac4}.nstld.com. and added NS {d|e|f}.nic.bank. on November 23
>
> Does that answer your question?

{a,b,c,d,e,f}.nic.bank and ac{1..4}.nstld.com seem to have
non-overlapping addresses.

I think this means that a simple update protocol (such as that
currently used for tzdata, or the root key and initial set of DNS
server address) will not be very reliable (at least until these
practices change).

I'm not sure if a different update protocol would be much of an
improvement over using the current with NSEC synthesis enabled.  (It
would be nice if resolver software allowed configuring that for the
root separately.)


From petr.spacek at nic.cz  Thu Nov 28 08:42:46 2019
From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=)
Date: Thu, 28 Nov 2019 09:42:46 +0100
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
Message-ID: <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>

On 27. 11. 19 21:49, David Conrad wrote:
> Petr,
> 
>> I think there is even more fundamental problem:
>> Someone has to pay operational costs of "the new system?.
> 
> The ?new system? is simply the existing network of resolvers, augmented to have the root zone. ?As far as I can tell, the operational cost would be in (a) ensuring the resolver is upgraded to support obtaining the root zone and (b) dealing with the fetch of the root zone with some frequency.

Oh, sorry, this is misunderstanding! My reference to "the new system" was meant to be "the new system for root zone distribution".
Please let me try again:

Even if "the new system for root zone distribution" is BitTorrent it still:
- (most likely) needs a set of static IP addresses to solve the bootstrap problem,
- trackers need to be highly resilient against DDoS,
- trackers most likely need to be anycasted to limit scope of DDoS.

I hypothetise that in the end requirements for "the new system for root zone distribution" will be fairly close to current requirements for current DNS root system... so I do not see where the cost reduction comes from.

Or in other words:
If current root system must survive 1 TB/s attack so must the "the new system for root zone distribution" system, unless we move to decenralized root.

Changing one centralized system to another does not solve the fundamendal problem of costly-to-defent-single-point-of-failure.

Hopefully it is clearer this time.
Petr ?pa?ek  @  CZ.NIC


> 
> There would be an additional cost, that of making the root zone available to myriads of resolvers, but I believe this is an easily handled issue.
> 
>> Personally I do not see how transition to another root-zone-distribution system solves the over-provisioning problem - the new system still has to be ready to absorm absurdly large DDoS attacks.
> 
> Two ways:
> - greater decentralization: there are a lot more resolvers than the number of instances root server operators are likely to ever deploy. While an individual resolver might melt down, the impact would only be the end users using that resolver (and it is relatively easy for a resolver operator to add more capacity, mitigate the attacking client, etc).
> - the cost of operating and upgrade the service to deal with DDoS is distributed to folks whose job it is to provide that service (namely the ISPs or other network operators that run the resolvers). ?Remember that the root server operators have day jobs, some of which are not particularly related to running root service, and they are not (currently) being compensated for the costs of providing root service.
> 
>> Have a look at?https://www.knot-dns.cz/benchmark/?. The numbers in charts at bottom of the page show that a *single server machine* is able to reply *all* steady state queries for the root today.
>> ...
>> Most of the money is today spent on *massive* over-provisioning. As an practical example, CZ TLD is over-provisiong factor is in order of *hunderds* of stead-state query traffic, and the root might have even more.
> 
> Yep. As mentioned before, steady state is largely irrelevant.
> 
> In my view, the fact that root service infrastructure funnels up to a (logical) single point is an architectural flaw that may (assuming DDoS attack capacity continues to grow at the current rate or even grows faster with crappy IoT devices) put the root DNS service at risk. ?One of the advantages of putting the root zone in the resolver is that it mitigates that potential risk.
> 
> Regards,
> -drc
> (Speaking for myself, not any organization I may be affiliated with)


From martijn at reening.net  Thu Nov 28 11:55:06 2019
From: martijn at reening.net (Martijn Reening)
Date: Thu, 28 Nov 2019 12:55:06 +0100
Subject: [dns-operations] [Solved] (not just) Quad9 denial of existence
 for _25._tcp.mx1.p01.antagonist.nl IN TLSA
In-Reply-To: <20191128025525.GH34850@straasha.imrryr.org>
References: <20191126042751.GD34850@straasha.imrryr.org>
 <b6e68d8d-e1b3-08ef-c7fd-ec8b39f2c9dd@reening.net>
 <20191126150938.GF34850@straasha.imrryr.org>
 <20191126160433.GG34850@straasha.imrryr.org>
 <20191128025525.GH34850@straasha.imrryr.org>
Message-ID: <66859a9f-3f2a-cb36-73e2-853f85bc57ee@reening.net>

In the first message I forgot to mention that I work for Antagonist.
Thank you for investigating this issue further. We have updated the glue
for this domain accordingly.

Several months ago we moved ns3.antagonist.de to a different server.
Unfortunately we have overlooked glue records for this domain. They were
only updated for ns1.antagonist.nl.

The old glue record pointed to the old nameserver that was still
running, but only served stale data. This server did not have the _tcp
ENT, because the _25._tcp TLSA record did not exist. The updated
nameserver should serve the same fresh data as ns1 and ns2.

Again, thank you for investigating this issue.

On 28/11/2019 03:55, Viktor Dukhovni wrote:
> Root cause found, the antagonist.nl domain has 3 listed nameservers:
> 
>     ns1.antagonist.nl.
>     ns2.antagonist.net.
>     ns3.antagonist.de.
> 
> but the IP address returned by the actual antagonist.de zone:
> 
>     ns3.antagonist.de. IN A 139.162.173.192
> 
> differs from the glue record returned from the .DE zone:
> 
>     ns3.antagonist.de. IN A 66.228.42.134
> 
> And it is this 66.228.42.134 (returned in the .DE glue) nameserver that is
> serving freshly signed denial of existence for _tcp.mx1.p01.antagonist.nl.
> 

-- 
Kind regards,
Met vriendelijke groet,

Martijn Reening
Systems and Network Engineer

From johnl at taugh.com  Thu Nov 28 14:34:58 2019
From: johnl at taugh.com (John Levine)
Date: 28 Nov 2019 09:34:58 -0500
Subject: [dns-operations] Questions on private nameservers registration
In-Reply-To: <f395a533-18a6-0326-ad8e-363c24ee5b02@wsly.de>
Message-ID: <20191128143458.D354CFDDC91@ary.qy>

In article <f395a533-18a6-0326-ad8e-363c24ee5b02 at wsly.de> you write:
>Another more question, can I put DE glues into other domain registry's 
>zone? For example, the COM's.

You only use glue records when resolving the NS address would
otherwise lead to a loop, so there's no .de glue in the .com zone.

EPP does have name server objects which you can export to different
registries to tell them that it's OK to use a name server, but those
don't make the zone include glue records.





From vladimir.cunat+ietf at nic.cz  Thu Nov 28 17:49:19 2019
From: vladimir.cunat+ietf at nic.cz (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=)
Date: Thu, 28 Nov 2019 18:49:19 +0100
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <alpine.DEB.2.20.1911262040430.17186@grey.csi.cam.ac.uk>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126154932.GA16734@jurassic.lan.banu.com>
 <alpine.DEB.2.20.1911262040430.17186@grey.csi.cam.ac.uk>
Message-ID: <5d9ac760-3c3e-aefd-753a-c9ee75e41d2e@nic.cz>

On 11/26/19 9:58 PM, Tony Finch wrote:
> Mirror zones (validated zone transfers) fall on the wrong side of the
> cost/benefit equation for me. But I might change my mind if there were
> better security for unauthenticated records (NS and glue)

These are why we only implemented the mechanism over HTTPS for now (in
addition to validating signatures).
https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling

Still, I believe that a small resolver instance only needs a few DNS
queries to root (per TTL), so switching everyone to always transferring
the whole root should increase the total traffic considerably, and HTTPS
and XoT are probably more expensive than DNS-over-UDP given the same
traffic amount.? That's where the aggressive-cache-only approach seems
nice, but (additionally) having full root would also avoid leaking any
of those garbage queries. (Except for those that hit an existing TLD,
but those can't be helped at the root level, and TLDs are generally too
big+dynamic for mirroring.)

--Vladimir


From paul at redbarn.org  Thu Nov 28 18:10:26 2019
From: paul at redbarn.org (Paul Vixie)
Date: Thu, 28 Nov 2019 18:10:26 +0000
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <c78523b7-812b-604f-6b3d-abb9939a9882@dns-oarc.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
 <c78523b7-812b-604f-6b3d-abb9939a9882@dns-oarc.net>
Message-ID: <3222692.X6rycYNCNm@linux-9daj>

On Wednesday, 27 November 2019 15:38:32 UTC Keith Mitchell wrote:
> ...
> 
> While AS112 makes a difference, it is far from ubiquitous or optimal.
> Probably there are gains to be made from more aggressive co-ordination
> and advocacy (*), but I suspect these would need stronger resource
> support from a more top-down source. It's far from the whole problem
> space, but makes some difference at the root for sure.

+1 except, there is no top.

-- 
Paul



From paul at redbarn.org  Thu Nov 28 18:10:26 2019
From: paul at redbarn.org (Paul Vixie)
Date: Thu, 28 Nov 2019 18:10:26 +0000
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <c78523b7-812b-604f-6b3d-abb9939a9882@dns-oarc.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
 <c78523b7-812b-604f-6b3d-abb9939a9882@dns-oarc.net>
Message-ID: <3222692.X6rycYNCNm@linux-9daj>

On Wednesday, 27 November 2019 15:38:32 UTC Keith Mitchell wrote:
> ...
> 
> While AS112 makes a difference, it is far from ubiquitous or optimal.
> Probably there are gains to be made from more aggressive co-ordination
> and advocacy (*), but I suspect these would need stronger resource
> support from a more top-down source. It's far from the whole problem
> space, but makes some difference at the root for sure.

+1 except, there is no top.

-- 
Paul



From tale at dd.org  Thu Nov 28 18:10:59 2019
From: tale at dd.org (Dave Lawrence)
Date: Thu, 28 Nov 2019 13:10:59 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <20191127031802.4CB6419B63FD@fafnir.remote.dragon.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>
 <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
 <20191127031802.4CB6419B63FD@fafnir.remote.dragon.net>
Message-ID: <24032.3507.458769.567104@gro.dd.org>

Paul Ebersman writes:
> mallman> I wonder if we're ever allowed to just decide this sort of
> mallman> thing is ridiculous old shit and for lots of reasons we can and
> mallman> should just garbage collect it away.
> 
> We aren't allowed as IETF/engineers. The world sort of is. ;)

I see the :) but I'm thinking the first sentence is serious.  

Given the consensus model of the IETF, I absolutely think we're
allowed to decide we no longer have to be backwards compatible with
everything in perpetuity. We can certainly roll out a spec which
mandates, to the IETF's best ability to mandate anything, a behavior
that is known to be problematic to ancient software.  Of course we'd
take into account just what sore of problematic that is and the
relative risk involved in coming to a decision about whether it's
acceptable, but I've never seen a hard requirement that "ridiculous
old shit" work indefinitely.

The rest of the world's developers and operators can of course decide
whether to go along with the new spec, exactly as they always have
been.

From paul at redbarn.org  Thu Nov 28 18:39:36 2019
From: paul at redbarn.org (Paul Vixie)
Date: Thu, 28 Nov 2019 18:39:36 +0000
Subject: [dns-operations] what's actually needed (Re: root? we don't need no
 stinkin' root!)
In-Reply-To: <3222692.X6rycYNCNm@linux-9daj>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <c78523b7-812b-604f-6b3d-abb9939a9882@dns-oarc.net>
 <3222692.X6rycYNCNm@linux-9daj>
Message-ID: <50807272.eE3EZppCZd@linux-9daj>

the ICIR paper on removing the root zone furthers the wrongheadedness of RFC 
7706, and both proceed from (at least) the misunderstanding of what metadata 
is actually needed by a recursive name server, and of the circumstances under 
which that data is sometimes not available.

most TLD's have a very small constituency of access, or in other words, most 
RDNS servers only utilize a small subset of the available root zone metadata. 
rather, it's the NS, AAAA/A glue, and DS RRsets of the whole chains leading to 
any popular (in relativized local use) domains for each/every RDNS.

the root name servers, while a political debacle, are highly available -- and 
can be made moreso if the community could decide to use DNSSEC rather than 
root server IP addresses as the primary method of verifying their content. 
this would mean making the root zone more like AS112 ("unowned anycast").

the problem of network partitions where some (perhaps large) set of distant 
resources (like DNS authority servers, including but by no means limited to 
the root zone's servers) become unavailable due to fiber cuts or government 
shutdowns, is disjoint from anything the ICIR paper, or RFC 7706, or RFC 7706-
bis, contemplates or addresses.

we need DNS leasing, or micro-secondary, depending on whether you come at this 
from a distributed file system or a distributed naming system background. 
speeds and capacities are now adequate to somewhat tighten the loose coherence 
of DNS. but it won't look like zone transfers and it won't be limited to the 
root zone.

-- 
Paul



From list-dns-operations at dragon.net  Thu Nov 28 18:56:09 2019
From: list-dns-operations at dragon.net (Paul Ebersman)
Date: Thu, 28 Nov 2019 10:56:09 -0800
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <24032.3507.458769.567104@gro.dd.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <20191126175654.0A51919B06D6@fafnir.remote.dragon.net>
 <ECE3EBC7-2979-42DB-9E1E-835233600340@icir.org>
 <20191127031802.4CB6419B63FD@fafnir.remote.dragon.net>
 <24032.3507.458769.567104@gro.dd.org>
Message-ID: <20191128185609.4815519C2CA5@fafnir.remote.dragon.net>

mallman> I wonder if we're ever allowed to just decide this sort of
mallman> thing is ridiculous old shit and for lots of reasons we can and
mallman> should just garbage collect it away.

ebersman> We aren't allowed as IETF/engineers. The world sort of is. ;)

tale> I see the :) but I'm thinking the first sentence is serious.  

tale> Given the consensus model of the IETF, I absolutely think we're
tale> allowed to decide we no longer have to be backwards compatible with
tale> everything in perpetuity.

Should have been clearer. My point is that we as the IETF can recommend
and specify but we have no control over what users/companies/vendors do
with it. And operationally, we have to be sympathetic to legacy and
obsolescence needs.

Things like DNS flag day are a good start, assuming we do stay flexible
with respect to such user needs.

From ietf-dane at dukhovni.org  Thu Nov 28 19:29:57 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Nov 2019 14:29:57 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
Message-ID: <20191128192957.GI34850@straasha.imrryr.org>

On Thu, Nov 28, 2019 at 09:42:46AM +0100, Petr ?pa?ek wrote:

> Please let me try again:
> 
> Even if "the new system for root zone distribution" is BitTorrent it still:
> - (most likely) needs a set of static IP addresses to solve the bootstrap problem,
> - trackers need to be highly resilient against DDoS,
> - trackers most likely need to be anycasted to limit scope of DDoS.
> 
> I hypothetise that in the end requirements for "the new system for root zone
> distribution" will be fairly close to current requirements for current DNS
> root system... so I do not see where the cost reduction comes from.
> 
> Or in other words:
> If current root system must survive 1 TB/s attack so must the "the new system
> for root zone distribution" system, unless we move to decenralized root.

Yes, but the expected probability of a 1 TB/s attack is likely different for a
file transfer service over TCP than it is for a one-shot query service over
UDP.  The chief reason being that refection of answers to forged source IPs is
not available with TCP, and so attacks on *other* systems via the root servers
are no longer attractive once the root servers just offer bulk data for
download via TCP.

So key question is whether the attacks we're seeing today are aimed at the root
servers themselves, or are DDoS reflection attacks on other systems.  Of course
once we're in the business of waving magic wands, it would be tr?s chic if all
network operators implemented BCP38, and compromised Internet of T!@#$% devices
were no longer able to mask their origin networks.

-- 
    Viktor.

From dot at dotat.at  Fri Nov 29 19:34:56 2019
From: dot at dotat.at (Tony Finch)
Date: Fri, 29 Nov 2019 19:34:56 +0000
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <20191128192957.GI34850@straasha.imrryr.org>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
 <20191128192957.GI34850@straasha.imrryr.org>
Message-ID: <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>

Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> refection of answers to forged source IPs is not available with TCP

Attackers can get a small amplification from SYN/ACK retries, and this is
being used in the wild.

https://www.darkreading.com/attacks-breaches/new-ddos-attacks-leverage-tcp-amplification-/d/d-id/1336339

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Variable 3 or less in southeast, southwesterly 3 to 5 in northwest.
Moderate, occasionally rough in north and slight in southeast. Showers. Good,
occasionally moderate.

From dot at dotat.at  Fri Nov 29 19:49:09 2019
From: dot at dotat.at (Tony Finch)
Date: Fri, 29 Nov 2019 19:49:09 +0000
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <87imn4bj32.fsf@mid.deneb.enyo.de>
References: <87d0ddm0q0.fsf@mid.deneb.enyo.de>
 <216D841C-2AB0-459E-8240-992E754E42BA@puck.nether.net>
 <87imn4bj32.fsf@mid.deneb.enyo.de>
Message-ID: <alpine.DEB.2.20.1911291935310.10401@grey.csi.cam.ac.uk>

Florian Weimer <fw at deneb.enyo.de> wrote:
>
> But does anyone swap out the name servers for a TLD over the course of
> five days?

Complete replacement of delegation NS RRsets happens fairly frequently. I
don't pay attention to the glue, tho, so I don't know how often these are
just renames as opposed to server platform changes.

One memorable example was .unicom back in June

https://twitter.com/fanf/status/1138372065541677056

The .mm delegation change on 7 Oct was a complete change of names and
addresses.

On 2 Nov, .in and their many IDN TLDs had a rename rather than a change of
addresses.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Whitby to Gibraltar Point: North 3 or 4, becoming variable 3 or less, then
east 3 or 4 later. Slight or moderate. Showers. Good.

From tih at hamartun.priv.no  Fri Nov 29 20:17:32 2019
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Fri, 29 Nov 2019 21:17:32 +0100
Subject: root? we don't need no stinkin' root!
In-Reply-To: <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk> (Tony
 Finch's message of "Fri, 29 Nov 2019 19:34:56 +0000")
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
 <20191128192957.GI34850@straasha.imrryr.org>
 <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
Message-ID: <m21rtqzbc3.fsf@thuvia.hamartun.priv.no>

Tony Finch <dot at dotat.at> writes:

> Attackers can get a small amplification from SYN/ACK retries, and this
> is being used in the wild.

Can you actually implement a TCP stack without that possibility?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

From dot at dotat.at  Fri Nov 29 20:22:37 2019
From: dot at dotat.at (Tony Finch)
Date: Fri, 29 Nov 2019 20:22:37 +0000
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <m21rtqzbc3.fsf@thuvia.hamartun.priv.no>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
 <20191128192957.GI34850@straasha.imrryr.org>
 <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
 <m21rtqzbc3.fsf@thuvia.hamartun.priv.no>
Message-ID: <alpine.DEB.2.20.1911292020070.10401@grey.csi.cam.ac.uk>

Tom Ivar Helbekkmo <tih at hamartun.priv.no> wrote:
>
> Can you actually implement a TCP stack without that possibility?

I vaguely speculate that it would be better to rely on SYN retries and
abolish SYN/ACK retries, but I have no idea what it might break.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
safeguard the balance of nature and the environment

From ietf-dane at dukhovni.org  Fri Nov 29 20:25:29 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 29 Nov 2019 15:25:29 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
 <20191128192957.GI34850@straasha.imrryr.org>
 <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
Message-ID: <20191129202529.GN34850@straasha.imrryr.org>

On Fri, Nov 29, 2019 at 07:34:56PM +0000, Tony Finch wrote:

> Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> >
> > refection of answers to forged source IPs is not available with TCP
> 
> Attackers can get a small amplification from SYN/ACK retries, and this is
> being used in the wild.
> 
> https://www.darkreading.com/attacks-breaches/new-ddos-attacks-leverage-tcp-amplification-/d/d-id/1336339

Thanks for the link, appreciated.  Perhaps the answer is that a future root
zone retrieval service should be available only via QUIC with always-on address
validation:

    https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1.1
    https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1

This should also facilitate data integrity.

-- 
    Viktor.

From ietf-dane at dukhovni.org  Fri Nov 29 20:25:29 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 29 Nov 2019 15:25:29 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
 <20191128192957.GI34850@straasha.imrryr.org>
 <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
Message-ID: <20191129202529.GN34850@straasha.imrryr.org>

On Fri, Nov 29, 2019 at 07:34:56PM +0000, Tony Finch wrote:

> Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> >
> > refection of answers to forged source IPs is not available with TCP
> 
> Attackers can get a small amplification from SYN/ACK retries, and this is
> being used in the wild.
> 
> https://www.darkreading.com/attacks-breaches/new-ddos-attacks-leverage-tcp-amplification-/d/d-id/1336339

Thanks for the link, appreciated.  Perhaps the answer is that a future root
zone retrieval service should be available only via QUIC with always-on address
validation:

    https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1.1
    https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1

This should also facilitate data integrity.

-- 
    Viktor.

From ietf-dane at dukhovni.org  Fri Nov 29 20:35:43 2019
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 29 Nov 2019 15:35:43 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <m21rtqzbc3.fsf@thuvia.hamartun.priv.no>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
 <20191128192957.GI34850@straasha.imrryr.org>
 <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
 <m21rtqzbc3.fsf@thuvia.hamartun.priv.no>
Message-ID: <20191129203543.GO34850@straasha.imrryr.org>

On Fri, Nov 29, 2019 at 09:17:32PM +0100, Tom Ivar Helbekkmo wrote:

> > Attackers can get a small amplification from SYN/ACK retries, and this
> > is being used in the wild.
> 
> Can you actually implement a TCP stack without that possibility?

Not in general, but if for a particular service the client always sends the
first application data message, then the server could make this known to the
TCP stack, and in that case the SYN+ACK retransmissions could be avoided,
because the client would retrasmit the SYN if the SYN+ACK was lost, and would
otherwise retransmit its initial message.

When the server sends the first message, it sadly needs to retransmit SYN+ACK,
because when the client's ACK is lost the client is otherwise stuck with an
apparently established connection, and nothing ever sent from the server.

Thus, for example, SMTP servers (over TCP) have no choice but to retransmit
SYN+ACK.

There is not presently a mechanism in any TCP stacks I know of for a server
to indicate that SYN+ACK retransmisison is optional because the client will
send first.

-- 
    Viktor.

From jgh at wizmail.org  Fri Nov 29 21:07:33 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Fri, 29 Nov 2019 21:07:33 +0000
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org>
 <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org>
 <f1313614-395d-19f0-b037-39c2292f57d9@nic.cz>
 <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org>
 <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz>
 <20191128192957.GI34850@straasha.imrryr.org>
 <alpine.DEB.2.20.1911291931230.10401@grey.csi.cam.ac.uk>
Message-ID: <8d906edf-cb5c-abc4-847c-f64b70543a45@wizmail.org>

On 29/11/2019 19:34, Tony Finch wrote:
> Attackers can get a small amplification from SYN/ACK retries, and this is
> being used in the wild.
> 
> https://www.darkreading.com/attacks-breaches/new-ddos-attacks-leverage-tcp-amplification-/d/d-id/1336339

This isn't small.  It'd be good to know _what_ is so broken:

"many devices on the Internet can be manipulated to retransmit more than
5,000 SYN-ACK packets in 60 seconds"

-- 
Cheers,
  Jeremy

From rubensk at nic.br  Sat Nov 30 01:32:04 2019
From: rubensk at nic.br (Rubens Kuhl)
Date: Fri, 29 Nov 2019 22:32:04 -0300
Subject: [dns-operations] root?  we don't need no stinkin' root!
In-Reply-To: <mailman.1141.1574879118.1398.dns-operations@lists.dns-oarc.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <mailman.1141.1574879118.1398.dns-operations@lists.dns-oarc.net>
Message-ID: <847884DE-D3FE-43F2-8950-E7F740D00B15@nic.br>


>> 
>> The data could have monetary value.  Passwords that are otherwise
>> difficult to come by might be leaking.
> 
> Hi Florian,
> 
> I can assure you that Verisign does not monetize the root server data.  If
> any other operators do, I'm not aware of it.
> 
> We do utilize root server data for research purposes from time-to-time.
> Recent examples include the KSK rollover and name collisions.  Less recent
> examples include understanding TTL/caching behavior and preparing for the
> root ZSK size increase.  When DDoS attacks happen, we often analyze the
> data to see if we can understand how and why it happened, and to be better
> prepared for the next one.


Note that the two paragraphs above contradict each other. The current RZM is known to use root server data as anti-competitive measures against new TLD operators with the label of name collision studies, including making studies that other parties can't reproduce due to being limited to DITL data. 


Rubens


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

From keith at dns-oarc.net  Sat Nov 30 17:31:15 2019
From: keith at dns-oarc.net (Keith Mitchell)
Date: Sat, 30 Nov 2019 12:31:15 -0500
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <847884DE-D3FE-43F2-8950-E7F740D00B15@nic.br>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <mailman.1141.1574879118.1398.dns-operations@lists.dns-oarc.net>
 <847884DE-D3FE-43F2-8950-E7F740D00B15@nic.br>
Message-ID: <90044c63-cbc3-6530-5268-e42be65725c7@dns-oarc.net>

On 11/29/19 8:32 PM, Rubens Kuhl wrote:

> including making studies that other parties can't reproduce due to
> being limited to DITL data.

DITL data is available to any party who signs an OARC Data Sharing
agreement.

Keith

From rubensk at nic.br  Sat Nov 30 20:11:36 2019
From: rubensk at nic.br (Rubens Kuhl)
Date: Sat, 30 Nov 2019 17:11:36 -0300
Subject: [dns-operations] root? we don't need no stinkin' root!
In-Reply-To: <90044c63-cbc3-6530-5268-e42be65725c7@dns-oarc.net>
References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org>
 <878so3oew0.fsf@mid.deneb.enyo.de>
 <A7D3BA19-F642-4A21-992F-EA19DDB3ED75@rfc1035.com>
 <87tv6rmwef.fsf@mid.deneb.enyo.de>
 <mailman.1141.1574879118.1398.dns-operations@lists.dns-oarc.net>
 <847884DE-D3FE-43F2-8950-E7F740D00B15@nic.br>
 <90044c63-cbc3-6530-5268-e42be65725c7@dns-oarc.net>
Message-ID: <AB9251C5-2E99-4622-A529-78F97B043213@nic.br>



> On 30 Nov 2019, at 14:31, Keith Mitchell <keith at dns-oarc.net> wrote:
> 
> On 11/29/19 8:32 PM, Rubens Kuhl wrote:
> 
>> including making studies that other parties can't reproduce due to
>> being limited to DITL data.
> 
> DITL data is available to any party who signs an OARC Data Sharing
> agreement.


Keith,

DITL data is the gold standard for such analysis. What I mentioned is that the RZM publishes studies that can't be reproduced due to use of other data(not DITL) only accessible to the RZM, and also try implying that DITL data doesn't capture reality due to being short lived, which is kinda like "I know better but I can't tell you why". 





Rubens