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

[Mark Allman]

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

An anecdote here ...

I crunched a day's worth of DNS traffic originated at ICSI (which is
pretty much a "small resolver instance") from mid-Oct (which just
happened to be handy).  The entire root zone file would be ~725
full-size TCP packets.  Our two main DNS resolvers together sent
nearly 63K queries to the root nameservers.

I am not arguing either of these is onerous for us.  But, the notion
that snarfing a MB of zone file is somehow a considerable increase
in traffic vs. what we impose on the roots now seems dubious.

allman
___
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]

>> On 11 Dec 2019, at 12:51, Stephane Bortzmeyer  wrote:
>>
>> IMHO, this is by far the biggest issue with your proposal: TLDs change
>> from one technical operator to another and, when it happens, all name
>> servers change at once.
>
> That’s not correct.
>
> In principle, they could all change at once, In reality, they
> don’t.

I wondered about this.  So, I crunched across our corpus of root
zone files, which spans from Apr 28 2009 to now (I stopped crunching
on Dec 11 2019).  We have one zone file per day (we miss a day here
or there due to glitches, but not many, the corpus is 3,500 days
long).  I found:

  - There are 1,578 TLDs that appear in the root zone file at some
point in the last 10 years.

  - Of those, 1,139 (72.2%) have at least one nameserver (by IP)
that is constant over the entire period the TLD is active.  (I'd
have not guessed it was this high!)

  - For the remaining 439 TLDs, for each day the TLD was active I
calculated how many days into the future would it be until none
of the current set of nameservers (by IP) would no longer be
listed.  For each TLD I took the minimum value.  That shows:

+ 173 TLDs (or 11.0% of all TLDs) at some point have a switch as
  Stephane describes.  I.e., there are no common IP addresses in
  the nameserver set between day X and day X+1.

+ Another 107 TLDs (or 6.8% of all TLDs) had a point where a
  zone file become outdated more in [2,7] days.

+ 75 TLDs (or 4.8% of all TLDs) had a point where a zone file
  become outdated in [8,30] days.

+ 84 TLDs (or 5.4% of all TLDs) only ever became outdated after
  more than 30 days.

FWIW.

allman
___
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 Stephane!

Thanks for the note.  I have been thinking about this point a bit.

> IMHO, this is by far the biggest issue with your proposal: TLDs
> change from one technical operator to another and, when it
> happens, all name servers change at once. Should your proposal be
> implemented, we would have to debug problems with root zones
> outdated by 1, 2, 3 months and some TLD working for some resolvers
> but not all. (True, we already have resolver-specific issues, but
> I think it would aggravate the problem.)
>
> This would have anti-competitive consequences, discouraging TLD
> holders to swap technical operators.

I get your point.  But, it's predicated on resolvers using a local
zone file that is "outdated by 1, 2, 3 months".  And, I can't really
quite figure out if that is realistic or, if it is, how much we
should care.  A few comments:

  - To be clear, the scenario is that someone has taken the step to
grab a root zone file and use it in the resolution process, but
then (a) have no effective update process to update the zone file or
(b) have a process that goes bad some point without anyone
noticing.  This would without a doubt happen if we shut down the
root nameservers and forced everyone to use local replicas.
But, I am hard pressed to convince myself it'd happen a lot or
that we should care about (/engineer around) such shoddy
operations.

  - Seems like if we took this approach to run without root
nameservers that we'd first design software to update local
replicas in an automated and robust fashion.  In other words,
this isn't something every operator is going to have to piece
together themselves.

  - To the extent that this is an issue, RFC 7706-style local roots
already have it.  So, this is not a new issue---but, the issue
might be bigger if more local roots existed.

  - Finally, I think there is some incentive to stay up-to-date.  We
do see problems when soft state becomes de-facto hard state
because it doesn't change except for once every eon or so.
E.g., the root hints file.  But, since the root zone file does
change pretty constantly (albeit in small ways), there is an
incentive to keep up, it seems to me.

I guess in sum, after some thought I am not ready to buy that this
situation you describe will constitute a big enough phenomenon to
exert anti-competitive pressure on TLD holders.

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

Re: [dns-operations] Flush DNSSEC from Cache

[Viktor Dukhovni]

On Wed, Dec 18, 2019 at 07:06:56AM +, Jay, Tim wrote:

> Will you please flush adp.com from your caches if you are doing DNSSEC
> validation?

Are you able to share any information about why this might be necessary?

In the last two-plus years of doing daily DNSSEC/DANE surveys, including
all signed .com delegations, I've never run into DS records for adp.com.
Were DS RRs added prematurely in error in the last ~12 hours, and then
quickly removed?

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

Re: [dns-operations] Flush DNSSEC from Cache

[Warren Kumari]

On Wed, Dec 18, 2019 at 9:10 AM Jay, Tim via dns-operations
 wrote:
>
>
>
>
> -- Forwarded message --
> From: "Jay, Tim" 
> To: "dns-operations@lists.dns-oarc.net" 
> Cc:
> Bcc:
> Date: Wed, 18 Dec 2019 07:06:56 +
> Subject: Flush DNSSEC from Cache
>
> Hello DNSOPS,
>
>
>
> Will you please flush adp.com from your caches if you are doing DNSSEC 
> validation?
>
>
>
> I would greatly appreciate a reply if you have been able to flush your cache 
> succusfully.
>
>


Flushed from Google's 8.8.8.8 resolvers

Cloudflare provides a page at https://cloudflare-dns.com/purge-cache/
-- I clicked some buttons there, and so it should be flushed from
1.1.1.1 as well...


A few years back Joe Abley and I had written "A Mechanism for
Remote-Triggered DNS Cache Flushes (DNS FLUSH)"
(draft-jabley-dnsop-dns-flush-00), and "Requirements for a Mechanism
for Remote-Triggered DNS Cache Flushes"
(draft-jabley-dnsop-flush-reqs-00). I've also got a draft,
presentation and some PoC code for creating a "DNS exchange" (a
concept similar to an IXP, but for DNS). This would allow sharing of
zonefiles, and also the ability to request cache flushes through an
automated, authenticated system. Other projects got in the way, but
I've been meaning to get back to this sometime...

W


>
> Thank you,
>
>
>
> Tim Jay
>
> Domain Client Services Manager, MarkMonitor |  Clarivate Analytics
>
> Phone +1.208.685.1789 |  Fax +1.208.389.5771
>
> 3540 East Longwing Lane, Suite 300 |  Meridian, ID 83646 |  US
>
>
>
> Have feedback? Contact my supervisor directly at olga.bou...@markmonitor.com
>
>
>
> NOTE: All transactions with MarkMonitor are subject to our standard terms and 
> conditions set forth at https://www.markmonitor.com/legal/tc_dm.php or the 
> specific terms and conditions of your written agreement with MarkMonitor. If 
> you do not agree to be bound by these terms and conditions, please contact us 
> immediately to cancel your order - (800) 337-7520.  MarkMonitor’s proposed 
> prices and terms of service are highly confidential and proprietary to 
> MarkMonitor, and may only be used for your internal purchasing purposes.  
> This information may not be shared with any third parties, except as 
> necessary in connection with any legal action or proceeding.  If you do not 
> agree with these confidentiality obligations, please notify the sender by 
> return e-mail, and delete or destroy all copies of this email and any 
> attachments.
>
>
>
>
>
>
>
>
> -- Forwarded message --
> From: "Jay, Tim via dns-operations" 
> To: "dns-operations@lists.dns-oarc.net" 
> Cc:
> Bcc:
> Date: Wed, 18 Dec 2019 07:06:56 +
> Subject: [dns-operations] Flush DNSSEC from Cache
> ___
> dns-operations mailing list
> dns-operations@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

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

[dns-operations] Flush DNSSEC from Cache

[Jay, Tim via dns-operations]

--- Begin Message ---
Hello DNSOPS,

Will you please flush adp.com from your caches if you are doing DNSSEC 
validation?

I would greatly appreciate a reply if you have been able to flush your cache 
succusfully.

Thank you,

Tim Jay
Domain Client Services Manager, MarkMonitor |  
Clarivate Analytics
Phone +1.208.685.1789 |  Fax +1.208.389.5771
3540 East Longwing Lane, Suite 300 |  Meridian, ID 83646 |  US

Have feedback? Contact my supervisor directly at 
olga.bou...@markmonitor.com

NOTE: All transactions with MarkMonitor are subject to our standard terms and 
conditions set forth at https://www.markmonitor.com/legal/tc_dm.php or the 
specific terms and conditions of your written agreement with MarkMonitor. If 
you do not agree to be bound by these terms and conditions, please contact us 
immediately to cancel your order - (800) 337-7520.  MarkMonitor's proposed 
prices and terms of service are highly confidential and proprietary to 
MarkMonitor, and may only be used for your internal purchasing purposes.  This 
information may not be shared with any third parties, except as necessary in 
connection with any legal action or proceeding.  If you do not agree with these 
confidentiality obligations, please notify the sender by return e-mail, and 
delete or destroy all copies of this email and any attachments.


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