Re: [dns-operations] Strange things at C root name server

[Bill Woodcock]

Yep, Alarig and Michael, sorry, did that Whois as I was on my way to bed.  
Thanks for the correction. 

-Bill


> On May 22, 2024, at 6:39 AM, Michael Sinatra  wrote:
> 
> 
> 
>> On 5/21/24 13:38, Elmar K. Bins wrote:
>> Re Stéphane,
>> bortzme...@nic.fr (Stephane Bortzmeyer) wrote:
>>> First, c.root-servers.net lags behind. It is at serial 2024051801
>>> while all other root name servers are at 2024052101.
>> the SOA part is discouraging, I'm sure their monitoring has picked that up, 
>> so
>> for some reason they might be unable to act.
>>> Second, c.root-servers.org (.org, the Web server) does not reply and
>>> its IP address is allocated to Orange Ivory Coast (which started to
>>> announce this prefix four days ago).
>> I can't find it allocated or assigned to Orange; I only see the /8 in
>> ARIN's records. Where did you see the allocation?
> 
> Just a reminder to folks: If you're querying ARIN's whois directly, either 
> via the BSD/MacOS 'whois -a' or 'whois -h whois.arin.net' CLI tool, or the 
> linuxish tool, which allows for the latter command only, you're only going to 
> see the allocation from ARIN and not the downstream rwhois server at Cogent, 
> which shows their further delegations.  This is also true if you use ARIN's 
> web (or presumably REST) interfaces.
> 
> Simply using 'whois 38.230.3.46' at the CLI of either the *BSD/MacOS tool or 
> the tool generally available for Linuxes will traverse the full rwhois chain 
> and show the reassignment to Orange Cote d'Ivoire.
> 
> Note that querying the IRR system also shows a route object with an origin AS 
> of 29571.
> 
> michael
> ___
> 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] Strange things at C root name server

[Bill Woodcock]

> On May 21, 2024, at 22:08, Stephane Bortzmeyer  wrote:
> Second, c.root-servers.org (.org, the Web server) does not reply and
> its IP address is allocated to Orange Ivory Coast (which started to
> announce this prefix four days ago).

When you say “is allocated to,” do you mean something other than that they’re 
BGP announcing 38.230.3.0/24?  Because the IANA and all five RIRs appear to me 
to be in agreement that 38.230.3.0/24 is still part of 38/8, and is still a 
legacy allocation to PSInet, and thus to their inheritor Cogent, in the ARIN 
region.

This appears to me to be a simple instance of BGP hijacking.  And, amusingly, 
an unintentional origination, so the one quadrant of the 
intentional/unintentional origin/path matrix which RPKI could potentially have 
helped with.

-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] DNS Operations

[Bill Woodcock]

> On Feb 15, 2024, at 23:29, Rubens Kuhl via dns-operations 
>  wrote:
> What’s your popularity metric ? 

Please don’t feed the trolls.

-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] .GL (Greenland) 2LD DS denial of existence problems

[Bill Woodcock]

Yes, that too.  There’s a bit of a laundry-list.

-Bill


> On Jun 20, 2023, at 8:47 AM, Mark Andrews  wrote:
> 
> Isn’t it more not copying the NS records into the GL zone so that the signer 
> will generate the correct NSEC3 chain?
> You could get away with missing this step pre-DNSSEC if parent and child 
> where served by the same set of servers but
> not now that DNSSEC exists and especially if the parent is signed.
> 
> Mark
> 
>> On 20 Jun 2023, at 16:13, Bill Woodcock  wrote:
>> 
>> Yes, the second-levels have been broken since the middle of last October.  
>> CentralNIC unexpectedly created new delegation points for the second-level 
>> domains, but has not yet copied the DS records down from the parent, nor 
>> created new ones of their own.  We remind them of the issue periodically, 
>> but no response thus far.
>> 
>>   -Bill
>> 
>> 
>> 
>>>> On Jun 20, 2023, at 4:23 AM, Viktor Dukhovni  
>>>> wrote:
>>> 
>>> The .GL TLD returns bogus NXDOMAIN responses to DS queries for:
>>> 
>>>  com.gl. IN DS ? ; NXDomain https://dnsviz.net/d/com.gl/ZJEMOQ/dnssec/
>>>  gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 
>>> 3600
>>>  gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl.  [...]
>>>  s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
>>> SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
>>>  s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>>  BBTTMJM743SRPQ6J4KQDIUC73E3C1HOA.gl. IN NSEC3 1 1 10 504d114b 
>>> BSHTF866A32E02RJ617EUE8CCP45A6V4 NS DS RRSIG
>>>  BBTTMJM743SRPQ6J4KQDIUC73E3C1HOA.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>>  6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
>>> 742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
>>>  6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>> 
>>>  edu.gl. IN DS ? ; NXDomain https://dnsviz.net/d/edu.gl/ZJEKYw/dnssec/
>>>  gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 
>>> 3600
>>>  gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl. [...]
>>>  s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
>>> SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
>>>  s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>>  O3DN0L28MEKMTHMNP658AQ4UUG4CDHTP.gl. IN NSEC3 1 1 10 504d114b 
>>> OE6EUSIJCPGO9R8RG0RO7Q9TPS7L9A46 NS DS RRSIG
>>>  O3DN0L28MEKMTHMNP658AQ4UUG4CDHTP.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>>  6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
>>> 742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
>>>  6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>> 
>>>  org.gl. IN DS ? ; NXDomain https://dnsviz.net/d/org.gl/ZJEMkg/dnssec/
>>>  gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 
>>> 3600
>>>  gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl. [...]
>>>  s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
>>> SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
>>>  s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>>  EB30Q0MC6UJD3MIGICRL31Q4SNSIT4T7.gl. IN NSEC3 1 1 10 504d114b 
>>> EE4KJQ89ME2PR0AOHKV4G9OACUF3367V NS DS RRSIG
>>>  EB30Q0MC6UJD3MIGICRL31Q4SNSIT4T7.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>>  6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
>>> 742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
>>>  6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 
>>> 2023070505 2023061805 39306 gl. [...]
>>> 
>>> All three 2LDs exist, are delegated, have SOA records and child zones.
>>> 
>>> -- 
>>>  Viktor.
>>> ___
>>> 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
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 



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

Re: [dns-operations] .GL (Greenland) 2LD DS denial of existence problems

[Bill Woodcock]

Yes, the second-levels have been broken since the middle of last October.  
CentralNIC unexpectedly created new delegation points for the second-level 
domains, but has not yet copied the DS records down from the parent, nor 
created new ones of their own.  We remind them of the issue periodically, but 
no response thus far.

-Bill



> On Jun 20, 2023, at 4:23 AM, Viktor Dukhovni  wrote:
> 
> The .GL TLD returns bogus NXDOMAIN responses to DS queries for:
> 
>com.gl. IN DS ? ; NXDomain https://dnsviz.net/d/com.gl/ZJEMOQ/dnssec/
>gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 
> 3600
>gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl.  [...]
>s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
> SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
>s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
>BBTTMJM743SRPQ6J4KQDIUC73E3C1HOA.gl. IN NSEC3 1 1 10 504d114b 
> BSHTF866A32E02RJ617EUE8CCP45A6V4 NS DS RRSIG
>BBTTMJM743SRPQ6J4KQDIUC73E3C1HOA.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
>6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
> 742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
>6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
> 
>edu.gl. IN DS ? ; NXDomain https://dnsviz.net/d/edu.gl/ZJEKYw/dnssec/
>gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 
> 3600
>gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl. [...]
>s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
> SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
>s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
>O3DN0L28MEKMTHMNP658AQ4UUG4CDHTP.gl. IN NSEC3 1 1 10 504d114b 
> OE6EUSIJCPGO9R8RG0RO7Q9TPS7L9A46 NS DS RRSIG
>O3DN0L28MEKMTHMNP658AQ4UUG4CDHTP.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
>6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
> 742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
>6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
> 
>org.gl. IN DS ? ; NXDomain https://dnsviz.net/d/org.gl/ZJEMkg/dnssec/
>gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 
> 3600
>gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl. [...]
>s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
> SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
>s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
>EB30Q0MC6UJD3MIGICRL31Q4SNSIT4T7.gl. IN NSEC3 1 1 10 504d114b 
> EE4KJQ89ME2PR0AOHKV4G9OACUF3367V NS DS RRSIG
>EB30Q0MC6UJD3MIGICRL31Q4SNSIT4T7.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
>6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
> 742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
>6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 
> 2023070505 2023061805 39306 gl. [...]
> 
> All three 2LDs exist, are delegated, have SOA records and child zones.
> 
> -- 
>Viktor.
> ___
> 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] Percentage of DoT/DoH requests for public resolvers?

[Bill Woodcock]

> On Jun 12, 2023, at 2:49 PM, Stephane Bortzmeyer  wrote:
> I'm looking for the current percentage of encrypted DNS requests
> vs. in-the-clear ones on public resolvers having DoT/DoH/DoQ.

I expect it will be different for each resolver, since they all have fairly 
distinct user communities, with different priorities.  John can give you a more 
specific answer on behalf of Quad9 once he’s awake out there on the Pacific 
coast.

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

Re: [dns-operations] Important change for the .ga TLD 6th june 2023

[Bill Woodcock]

> On Jun 2, 2023, at 3:53 PM, Stephane Bortzmeyer  wrote:
> On Fri, Jun 02, 2023 at 11:03:19AM +0300,
> Frank Habicht  wrote 
>> I'm not involved at all, but wondering:
>> no webpage for registrants to check whether their domain will 'survive'?
> The way I see it (disclaimer: I don't work for ANINF), if you
> registered through a registrar, you're probably safe (check the list
> of registrars in , and check with your
> registrar), if you registered directly from Freenom, you're probably
> not safe (Freenom did not send the data to the registry).

There’s a tremendous amount of malware and phishing, and even some national 
military cyber-offensive stuff, in the domains that Freenom gave away for free. 
 Each of the countries that’s repatriating gets to make its own policy decision 
about how it wants to handle those, but most of them seem to be leaning toward 
“flush all the bad stuff and let people re-justify if they can.”  Having looked 
closely at the registrations, I can say that I have pretty high confidence that 
very few good domains are likely to get caught up with the bad, in that 
flushing process, and the good ones should be able to re-authenticate 
themselves to the legit registry.

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

Re: [dns-operations] Why did .KE go insecure? ns36.cdns.net

[Bill Woodcock]

> On Sep 23, 2022, at 7:27 PM, Jacques Latour  wrote:
> Just looking quickly, if you look back in dnsviz on Sept 15, I think a KSK 
> roll over didn't go as plan...

That was not the root cause.  I’m sure they’ll discuss it when they’re ready to.

-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] Why did .KE go insecure? ns36.cdns.net

[Bill Woodcock]

> On Sep 23, 2022, at 6:09 PM, Jan-Piet Mens via dns-operations 
>  wrote:
> 
> 
> From: Jan-Piet Mens 
> Subject: Why did .KE go insecure? ns36.cdns.net
> Date: September 23, 2022 at 6:09:04 PM GMT+2
> To: dns-operations@lists.dns-oarc.net
> 
> 
> Out of curiousity, does anybody know why .KE went insecure just after
> 2022-09-15 18:37Z [1]?  They appear to have removed all DNSSEC related data
> meanwhile [2].

Yes.  I imagine they’ll make an announcement at some point.  It wasn’t to do 
with a failure of DNSSEC systems.

-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] Response to the USG proposal to use MTA-STS

[Bill Woodcock]

>> Il 21/09/2021 00:38 Wes Hardaker  ha scritto:
>> 
>> Viktor and I have written a response to discuss the USG's proposal [1-3]
>> to use MTA-STS for securing E-mail (as opposed to DANE-SMTP).

PCH has also submitted a response along the same lines, also noting that the 
USG breaches which occasioned DHS/CISA Emergency Directive 19-01 used the CA 
cert exploit which MTA-STS is vulnerable to, but DANE-SMTP is not.

-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 DNSSEC Validation?

[Bill Woodcock]

> On Mar 1, 2021, at 9:31 PM, Wes Hardaker  wrote:
> 
> "John Todd"  writes:
> 
>> Zones under .GOV have been a continuous challenge, as have those
>> within .MIL.
> 
> FYI, if you're interested in looking at hard facts, I'll direct your
> attention to Viktor and my stats page that specifically looks for
> percentage of working domains within TLDS.  If you go to
> https://stats.dnssec-tools.org/ and look at the TLD graphs tab at the
> bottom, you can compare each TLD along with its history of success in
> DNSSEC valid subdomains.

The critical question is where you get the list of subdomains.  It’s easy to 
put together a list of short subdomains that validate.  It’s the long ones that 
get problematic.

-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 DNSSEC Validation?

[Bill Woodcock]

> On Mar 1, 2021, at 9:12 AM, Petr Špaček  wrote:
> In my experience negative trust anchors for big parts of MIL and/or GOV are 
> way more common, let's not pick specifically on Quad9. For periods of time I 
> have seen with other big resolver operators as well.
> IMHO resolver market economics are going against DNSSEC security. If 
> resolution does not work on one operator people routinely switch to other 
> where it "works", either because they do not validate at all, or because 
> their ops team already added negative trust anchor.
> The only way to fix this is mutual agreement among operators to stop working 
> around someone else's mistakes.

Yep, exactly.

> Are there operators willing to participate in such effort?

We’ve been pushing for it for several years without gaining traction yet.  We’d 
very much like others to come to the table.

I spent a bunch of time talking with John Todd, our General Manager, about this 
last night, and he’s writing up a more official Quad9 response to this thread.

-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 DNSSEC Validation?

[Bill Woodcock]

Hi. Speaking from Quad9’s board, rather than the operations side, resources are 
scarce and demand is enormous. We put in negative trust anchors where safe and 
necessary to keep things working for actual users, because if we don’t, we get 
drowned by support calls. And, like any donation-funded open project, donors 
are expecting us to use the resources they’ve given us to protect people, not 
to subsidize other people’s science projects. Your experiment is not 
distributing malware through .GOV or .MIL, therefore you have no reasonable 
expectation that we, our donors, and our users should absorb the externalized 
costs of your experiment. 

There, your experiment was a success: you learned something, just not what you 
were expecting to learn. 

But please think twice before putting an experiment in a production domain. 
This is exactly the sort of reason people normally register independent domains 
for beacons.

-Bill


> On Feb 28, 2021, at 09:52, Florian Weimer  wrote:
> 
> * Winfried Angele:
> 
>> I guess they've turned off validation for irs.gov because of a
>> former failure.
> 
> I think it goes beyond that.  It extends to GOV and MIL as a whole, it
> seems.
> ___
> 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] [EXT] .iq contacts?

[Bill Woodcock]

> On May 29, 2020, at 4:52 PM, Jacques Latour  wrote:
> 
> FWIW, replied offline with TLD-OPS contact info.

Anybody other than Saif?

-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] [Ext] Something happening in the root?

[Bill Woodcock]

So it’s been a week…  Cloudflare folks, have you published a post-incident 
analysis yet?

-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

[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] 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!

[Bill Woodcock]

> 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



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 and critical dns server caching

[Bill Woodcock]

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@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] gov.mu inconsistency

[Bill Woodcock]

On Nov 6, 2014, at 3:23 PM, Casey T. Deccio ca...@deccio.net wrote:

 
 On Nov 6, 2014, at 5:37 PM, S Moonesamy sm...@elandsys.com wrote:
 
 At 13:48 06-11-2014, Casey Deccio wrote:
 There are clearly two versions of the zone being served by gov.mu servers.  
 If the value of the serials is any indicator of date (as it appears), then 
 udns1.tld.mu and anycast1.irondns.net are serving a version of the zone 
 that is about ten months newer than that being served by ns{1,2,3}.gov.mu 
 (2014110646 vs. 2014010572).
 
 The strange part (re. date) is that I got a serial of 2014010166 on 7 
 October from a resolver.
 
 Weird.  But of course serial values resembling dates don't necessarily mean 
 that the value is actually derived from a current date.  There are instances 
 where dates were once used but an incremental scheme took over, so the serial 
 value still resembles a date--though not a current one.  In this case, who 
 knows?
 
 Casey

Looping in Yann and Viv, assuming one of them knows who works the gov 
delegation.

-Bill






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

Re: [dns-operations] It's begun...

[Bill Woodcock]

On Oct 23, 2013, at 1:11 PM, Rick Wesson r...@support-intelligence.com wrote:

 Does ICANN have a root-zone announce list? I remember hearing about it being 
 developed, but can't locate the list subscribe.

Here's how I found out about it:

http://blog.icann.org/2013/10/first-new-gtlds-get-the-green-light-for-delegation/

-Bill






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

Re: [dns-operations] Anycast supernodes

[Bill Woodcock]

On Aug 14, 2013, at 6:22 AM, Gavin Brown gavin.br...@centralnic.com wrote:
 I've come across a suggestion that an anycast DNS network should, amongst the 
 members of the network, include one supernode that's provisioned with so 
 much bandwidth and computing capacity that it can withstand a DDoS attack of 
 almost any size.

Best practice is to include a _subset_, generally more than one, that have 
global transit, as opposed to just regional peering, for the purpose you cite.  
We're moving from ten global nodes to twenty, currently.

All nodes should be able to withstand a DDoS originating from the set of 
machines to which it's visible.  Globally-visible nodes must thus be able to 
withstand much larger DDoSes than nodes that are only visible through peering, 
to a limited set of machines.

 An attack could knock out every other node in the network, but the overall 
 service would keep working because this node would remain up, handling all 
 the traffic.

This is not correct.  A DDoS will not knock out all of the local nodes, because 
(a) things don't scale that way, and (b) it won't be able to reach all of the 
local nodes.  If anything, a large DDoS will knock out a too-small pool of 
globally-visible nodes, while many much smaller ones will remain up, serving 
their local constituencies.

 20Gbps has been suggested as an appropriately fat pipe

We do 40, but yeah, 20 is better than less.

 This approach means that Anycast is only really being used for
 resilience and to improve response times…

Yes…

 ...during normal operations, and that being able blackhole attack traffic is 
 not a useful feature of Anycast.

…but I'm not sure where you're going with this part.  I think being able to 
drop attack traffic while answering valid queries is a central goal for any DNS 
system.  It's not a feature of anycast per se.

 Are there Anycast deployments out there that have supernodes like this?

All the mature ones have multiple supernodes like this.  They're generally 
called global nodes, since they're distinguished by their global transit 
routing, rather than by being larger, although that's also true for many or 
most of them.

 Now that there are attacks as big as 300Gbps,
 could you ever rely on such a design to guarantee protection from DDoS
 attacks?


Do the math.

-Bill Woodcock
 Research Director
 Packet Clearing House







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