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: 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: 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: References: Message-ID: Verisign are generally responsive, and can get you both root and TLD. -Bill > On Nov 9, 2019, at 07:28, Mehmet Akcin 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: References: Message-ID: On Sat, Nov 9, 2019 at 3:43 AM Bill Woodcock 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 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: References: 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 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: References: Message-ID: <5E7F884F-0EBB-4A36-8EF6-730360CC8AAC@nic.br> > On 9 Nov 2019, at 03:00, Mehmet Akcin 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <5E7F884F-0EBB-4A36-8EF6-730360CC8AAC@nic.br> Message-ID: 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 wrote: > > > On 9 Nov 2019, at 03:00, Mehmet Akcin 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: 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org> Message-ID: On Wed, Oct 30, 2019 at 11:30 PM Mark Andrews wrote: > > On 31 Oct 2019, at 12:02 am, Bob Harold wrote: > > On Tue, Oct 29, 2019 at 9:07 PM Paul Vixie 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: -- 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org> Message-ID: On Wed, Oct 30, 2019 at 7:31 PM Mark Andrews wrote: > > > > > On 31 Oct 2019, at 12:02 am, Bob Harold wrote: > > > > > > On Tue, Oct 29, 2019 at 9:07 PM Paul Vixie 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: References: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org> Message-ID: > On Nov 10, 2019, at 8:30 PM, Matt Nordhoff 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: > > 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: (Mehmet Akcin's message of "Fri, 8 Nov 2019 22:00:14 -0800") References: 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: References: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org> Message-ID: Viktor Dukhovni 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 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] [2] [3] 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: References: 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: <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: <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: References: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.org> Message-ID: <26c5a603-bbc3-424b-46d4-0b8883c5ecb2@redbarn.org> Viktor Dukhovni wrote on 2019-11-10 20:32: >> ... >> >> > > 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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: <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: <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 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: <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: <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 wrote: > >> On Nov 11, 2019, at 2:36 PM, Dave Lawrence 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: <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: > On Nov 11, 2019, at 4:41 PM, Mark Andrews 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: References: Message-ID: 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 wrote: > > ? > >>> On Nov 11, 2019, at 4:41 PM, Mark Andrews 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: References: Message-ID: > > On Nov 11, 2019, at 7:26 PM, Mark Andrews 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: <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net> Message-ID: James Stevens 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 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: <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: Viktor Dukhovni 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 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: References: <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net> 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 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: <40f86b5c-79a4-3079-fb7e-e9736f764ace@jrcs.net> <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: 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: 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: References: Message-ID: 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 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: 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: References: 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 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: 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: <0b5a381804cc4e1e852f3818275b990c@cira.ca> Message-ID: Jake Zack 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 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: References: <0b5a381804cc4e1e852f3818275b990c@cira.ca> Message-ID: 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 wrote: > > Jake Zack 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 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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: Viktor Dukhovni wrote on 2019-11-12 15:26: >> On Nov 12, 2019, at 2:32 PM, Paul Vixie 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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 wrote: > >> On Nov 12, 2019, at 2:32 PM, Paul Vixie 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: (Paul Vixie's message of "Tue, 12 Nov 2019 15:59:23 -0800") References: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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: <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: 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: References: Message-ID: 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" 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: References: Message-ID: > On 13 Nov 2019, at 06:25, Wesley Peng 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: <803b6a2d-742a-a64d-92e5-d35b347ed298@redbarn.org> <4F7272A5-D213-4FD0-9E87-20BB53BD50CE@isc.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> <877e449gzf.fsf@mid.deneb.enyo.de> Message-ID: Florian Weimer 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 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: 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: References: Message-ID: 5/3/2020 (March) On Sat, Nov 16, 2019 at 19:09 Ond?ej Sur? 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: 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: References: 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 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: 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 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 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: 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: <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 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: <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 wrote: > > On 11/11/19 11:57 AM, Viktor Dukhovni wrote: >>> On Nov 11, 2019, at 2:36 PM, Dave Lawrence 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 : type OPT Name: 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 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 > : type OPT > Name: > 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: Forwarded to TLD-OPS. >-----Original Message----- >From: dns-operations 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, 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: 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 on behalf of Wesley Peng Date: Monday 25 November 2019 at 15:22 To: "Elmar K. Bins" Cc: Dns-Operations 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, > 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: 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, 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 on behalf of Wesley Peng > Date: Monday 25 November 2019 at 15:22 > To: "Elmar K. Bins" > Cc: Dns-Operations > 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, 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: 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 on behalf of Wesley Peng Date: Monday 25 November 2019 at 15:45 To: Dns-Operations 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, > 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 on behalf of Wesley Peng Date: Monday 25 November 2019 at 15:22 To: "Elmar K. Bins" Cc: Dns-Operations 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, > 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: 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, 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 on behalf of Wesley Peng > Date: Monday 25 November 2019 at 15:45 > To: Dns-Operations > 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, 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 on behalf of Wesley Peng > > Date: Monday 25 November 2019 at 15:22 > > To: "Elmar K. Bins" > > Cc: Dns-Operations > > 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, 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: 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, 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: 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 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: 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: > On 25 Nov 2019, at 20:54, Florian Weimer 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: (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> Message-ID: <87tv6rmwef.fsf@mid.deneb.enyo.de> * Jim Reid: >> On 25 Nov 2019, at 20:54, Florian Weimer 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> <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> <87tv6rmwef.fsf@mid.deneb.enyo.de> Message-ID: 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: 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: 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> <87tv6rmwef.fsf@mid.deneb.enyo.de> Message-ID: <5745DC33-41CF-425E-9D96-304F37E0469E@rfc1035.com> > On 25 Nov 2019, at 22:19, Florian Weimer 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> <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 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> <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 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> <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 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> <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 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> <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 wrote: >> On 26 Nov 2019, at 09:16, Florian Weimer > 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: 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 wrote: > > ?On Nov 26, 2019, at 11:33 AM, Jim Reid wrote: >>> On 26 Nov 2019, at 09:16, Florian Weimer 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: 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> <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: 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> <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 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> <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: > On 26 Nov 2019, at 12:46, David Conrad 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: References: <20191126042751.GD34850@straasha.imrryr.org> 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: References: <20191126042751.GD34850@straasha.imrryr.org> 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: 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> <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 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 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> <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: 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 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 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: 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <20191126175654.0A51919B06D6@fafnir.remote.dragon.net> 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <20191126175654.0A51919B06D6@fafnir.remote.dragon.net> Message-ID: 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 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 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <878so3oew0.fsf@mid.deneb.enyo.de> <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: <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 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <20191126175654.0A51919B06D6@fafnir.remote.dragon.net> Message-ID: 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: 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> <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 > wrote: >>> On 26 Nov 2019, at 09:16, Florian Weimer > 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). 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> <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 wrote: > > * Jim Reid: > >>> On 25 Nov 2019, at 20:54, 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. 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: 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 wrote: > >> On Nov 25, 2019, at 9:54 PM, Florian Weimer 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: 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> <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> <5db0b8e9-b460-a650-2b76-cd23f6561167@nic.cz> Message-ID: 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org> 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/ . 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: 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 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> <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: References: <38789521-8b38-03ea-b818-0cc9c8019b62@wsly.de> <36d36e82-05d9-9344-b8ad-ee05c02d1083@saltant.com> Message-ID: 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 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 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 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 wrote: > > * Ond?ej Sur?: > >>> On 27 Nov 2019, at 23:08, Florian Weimer 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> <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> <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: Message-ID: <20191128143458.D354CFDDC91@ary.qy> In article 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <20191126154932.GA16734@jurassic.lan.banu.com> 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> 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> <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> <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> <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> <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> <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org> <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz> <20191128192957.GI34850@straasha.imrryr.org> Message-ID: Viktor Dukhovni 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 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: Florian Weimer 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 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: (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> <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org> <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz> <20191128192957.GI34850@straasha.imrryr.org> Message-ID: Tony Finch 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org> <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org> <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz> <20191128192957.GI34850@straasha.imrryr.org> Message-ID: Tom Ivar Helbekkmo 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 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org> <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org> <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz> <20191128192957.GI34850@straasha.imrryr.org> Message-ID: <20191129202529.GN34850@straasha.imrryr.org> On Fri, Nov 29, 2019 at 07:34:56PM +0000, Tony Finch wrote: > Viktor Dukhovni 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org> <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org> <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz> <20191128192957.GI34850@straasha.imrryr.org> Message-ID: <20191129202529.GN34850@straasha.imrryr.org> On Fri, Nov 29, 2019 at 07:34:56PM +0000, Tony Finch wrote: > Viktor Dukhovni 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org> <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org> <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz> <20191128192957.GI34850@straasha.imrryr.org> 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <4E146F95-4C66-45F0-83E8-9C17577EE02E@icir.org> <7C1E6BCD-CFFC-4ED0-9DDF-F00FDC0BAE52@sury.org> <520D7E1C-5EA2-499D-9F4C-B31A850728B1@virtualized.org> <08c0bded-58a6-9939-1359-83993aa65bf9@nic.cz> <20191128192957.GI34850@straasha.imrryr.org> 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: References: <0BB51D1E-150D-4C52-9850-5C0AD0994458@icir.org> <878so3oew0.fsf@mid.deneb.enyo.de> <87tv6rmwef.fsf@mid.deneb.enyo.de> 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: 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> <87tv6rmwef.fsf@mid.deneb.enyo.de> <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> <87tv6rmwef.fsf@mid.deneb.enyo.de> <847884DE-D3FE-43F2-8950-E7F740D00B15@nic.br> <90044c63-cbc3-6530-5268-e42be65725c7@dns-oarc.net> Message-ID: > On 30 Nov 2019, at 14:31, Keith Mitchell 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