Re: [dns-operations] root? we don't need no stinkin' root!

[George Michaelson]

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@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Paul Ebersman]

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 . 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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Mark Allman]

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@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Tony Finch]

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.finchhttp://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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Paul Ebersman]

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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Paul Ebersman]

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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[John Kristoff]

On Mon, 25 Nov 2019 20:30:32 +
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

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 denial of existence for _25._tcp.mx1.p01.antagonist.nl IN TLSA

[Viktor Dukhovni]

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 2019120500 
2019111400 47684 antagonist.nl. 
TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT 
wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN NSEC3 1 0 1 AB 
D04COHDERT50P43FHSP1N5F7LDVTORH7 A  RRSIG
cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 
86400 2019120500 2019111400 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 2019120500 2019111400 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 2019120500 2019111400 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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Mukund Sivaraman]

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
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 denial of existence for _25._tcp.mx1.p01.antagonist.nl IN TLSA

[Bill Woodcock]

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

-Bill



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 denial of existence for _25._tcp.mx1.p01.antagonist.nl IN TLSA

[Viktor Dukhovni]

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  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 2019120500 
2019111400 47684 antagonist.nl. 
TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT 
wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 
86400 2019120500 2019111400 47684 antagonist.nl. 
5KPt3wExlfKg4tZJ1fdR1xhnj8x8DsmgYR2+pCHkcc041thw3E6jQCfY 
CESVytcQcp6Zb/uJ3zxNXExJkEzZoQ==
i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 
86400 2019120500 2019111400 47684 antagonist.nl. 
Wrzps6dY9zhq14kBiFp0KwDqdkMtceOMV2cMKPkznhxFcsmpsTazZX1Z 
MAw/565cRwpWRoU5LuGNzGHg3ZstUQ==
g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 
86400 2019120500 2019111400 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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Roy Arends]

> 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


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Roy Arends]

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@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 denial of existence for _25._tcp.mx1.p01.antagonist.nl IN TLSA

[Martijn Reening via dns-operations]

--- Begin Message ---
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 
2019120500 2019111400 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  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 
> 2019120500 2019111400 47684 antagonist.nl. 
> TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT 
> wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
>     cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 
> 86400 2019120500 2019111400 47684 antagonist.nl. 
> 5KPt3wExlfKg4tZJ1fdR1xhnj8x8DsmgYR2+pCHkcc041thw3E6jQCfY 
> CESVytcQcp6Zb/uJ3zxNXExJkEzZoQ==
>     i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 
> 86400 2019120500 2019111400 47684 antagonist.nl. 
> Wrzps6dY9zhq14kBiFp0KwDqdkMtceOMV2cMKPkznhxFcsmpsTazZX1Z 
> MAw/565cRwpWRoU5LuGNzGHg3ZstUQ==
>     g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 
> 86400 2019120500 2019111400 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

--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Mark Allman]

> 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
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Bill Woodcock]

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@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

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

Thanks!

allman


--
https://www.icir.org/mallman/
@mallman_icsi
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[David Conrad]

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)



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Florian Weimer]

* 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.)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

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



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Florian Weimer]

* 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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Jim Reid]

> 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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

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

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


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations