Re: [dns-operations] [Ext] K-root in CN leaking outside of CN

[Ray Bellis]

On 07/11/2021 09:28, Ray Bellis wrote:

There most certainly were - a similar leak/poison pattern was 
detected from an I root node hosted in China in March 2010.


and checking our own records, we've had F root servers in China since at
least 2006.

However we announce our Anycast prefixes "NO_EXPORT" and make it very
clear that our routes must not propagate beyond the border.

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

Re: [dns-operations] [Ext] K-root in CN leaking outside of CN

[Ray Bellis]

On 06/11/2021 20:20, Manu Bretelle wrote:


I believe back in 2013 there were no root servers in China


There most certainly were - a similar leak/poison pattern was
detected from an I root node hosted in China in March 2010.

I recall the date because Roy Arends and I had previously been studying
the spoofed answers returned by the Great Firewall of China, and then
reports of incorrect answers being seen outside of China surfaced during
a DNS session at IETF 77 at Anaheim.

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

Re: [dns-operations] .iq contacts?

[Ray Bellis]

On 28/05/2020 22:56, Viktor Dukhovni wrote:

> Indeed this looks rather precarious, and the SOA serial number is not
> any higher on the other remaining server, the expiration time is 7 days,
> so not much time left if the primary went down in the 21st.
> 
> The MX record for cmc.iq is: cmc.iq. IN MX 0 in.hes.trendmicro.eu.  This
> might be useful for reaching "hostmas...@cmc.iq" should the zone expire
> in the meantime.  IANA lists a technical contact of "it...@cmc.iq":
> 

The ISC SNS service was actually due to be shut down on January 31st but
there's been a few malingerers, including .iq

We've been trying to reach them for *months* via many different comms
channels, to no avail.

However this potential failure of all listed NS servers makes this
somewhat more urgent.

Ray

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

[dns-operations] .iq contacts?

[Ray Bellis]

Has anyone got any working contacts whatsoever at .iq (Iraq?)

Their hidden master has been offline for about a week and of the four
name servers two are already returning SERVFAIL following the elapsing
of the SOA expiry timer and ours (sns-pb.isc.org) is due to follow suit
very soon.

When that happens there'll only be one functioning NS for the ccTLD, and
for all I know that one might be about to expire the zone too.

thanks,

Ray Bellis
Director of DNS Operations, ISC.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] solutions for DDoS mitigation of DNS

[Ray Bellis]

On 02/04/2020 11:10, Davey Song wrote:
> I'm very confused that why people on the list are suggesting RRL (even
> BCP38) to the victim of DoS attack? If I remember correctly, the goal of
> both RRL and BCP38 is to reduce the chance of participating the attack
> as a innocent helper.
> 
> In the introduce of RRL (https://kb.isc.org/docs/aa-01000)  , it goes :
> "RRL helps mitigate DNS denial-of-service attacks by reducing the rate
> at which authoritative servers respond to high volumes of malicious
> queries. "  
> 
> Please correct me .

The OP described a spoofed-source amplification attack.

They are not the "victim", but the unwilling participant.

RRL is the correct solution for this class of attack.

Ray

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

Re: [dns-operations] solutions for DDoS mitigation of DNS

[Ray Bellis]

On 02/04/2020 10:12, Tessa Plum wrote:

> All the packages were DNS requests, some queries like 'dig domain.com any'.
> but their IP address seems spoofed.
> A request from the fake address to our nameserver, but nameserver try
> its best to reply to this unreal address.

If it's a recursive server, apply an ACL so that only expected clients
can query.

If it's an authoritative server, turn on Response Rate Limiting (RRL) if
it's BIND, or the equivalent feature if is isn't.

Ray

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

[Ray Bellis]

On 25/02/2020 18:45, Paul Wouters wrote:

> I understand mistakes happen, and we can look forward at improved
> monitoring of the root zone and its anycast clouds. But this statement
> in the report seems a weak excuse for lowering the bar of expectations
> we have from root zone operators.

That statement was supposed to be more in the context of DNS server
implementors rather than operators.

In this particular event the failure was intermittent, dependent on the
previous pattern of queries to the server, and also dependent on the
zone being queried.  It was an edge case that wasn't being tested for,
but now is.

Ray
___
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?

[Ray Bellis]

On 30/01/2020 13:30, Ray Bellis wrote:

> We won't be publishing anything before then, but in practise any public
> report is unlikely to say much that wasn't already disclosed on the day
>  (see my email of 21:44 UTC on 2020/01/23).

Our incident report is now online at:

<https://www.isc.org/docs/f-root/incident-2020-01.pdf>

Ray Bellis
Director of DNS Operations, ISC.

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

[Ray Bellis]

On 30/01/2020 11:19, Bill Woodcock wrote:

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

ISC has scheduled a post-mortem meeting with Cloudflare during NANOG.

We won't be publishing anything before then, but in practise any public
report is unlikely to say much that wasn't already disclosed on the day
 (see my email of 21:44 UTC on 2020/01/23).

The one detail I can add now is that we only received reports of one
(unnamed) resolver implementation being affected and that its failure to
cope was also considered a bug.  It was only the combination of the two
bugs together that caused any operational issue.

cheers,

Ray

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

[Ray Bellis]

On 23/01/2020 21:15, Paul Hoffman wrote:

> Ad the problem seems fixed now, at least from the vantage points
> I use (which hit Cloudflare at various places).

There was a problem with some Cloudflare operated instances
intermittently returning answers without glue for some TLDs, which was
causing some resolvers to have issues.

The cause was identified, and so far as possible routes to those nodes
were withdrawn while a fix was being rolled out.

The fix is now in place and the prefixes are being re-advertised.

Ray Bellis
Director of DNS Operations, ISC.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

[Ray Bellis]

On 10/10/2019 04:51, Viktor Dukhovni wrote:


 $ traceroute6 f.root-servers.net.
  1  tunnel545690.tunnel.tserv4.nyc4.ipv6.he.net  8.442 ms  6.772 ms  7.252 
ms
  2  ve422.core1.nyc4.he.net  4.641 ms  3.155 ms  5.392 ms
  3  100ge16-1.core1.ash1.he.net  10.781 ms  21.786 ms  8.046 ms
  4  100ge10-2.core1.lax1.he.net  65.768 ms  63.279 ms  62.687 ms
  5  * * *
  6  * * *
  7  * * *
  8  * * *
  9  * *^C


Thanks for the report - we'll look into this.

Ray Bellis
Director of DNS Operations, ISC.

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

Re: [dns-operations] resolvers considered harmful

[Ray Bellis]

On 23 Oct 2014, at 16:11, David Conrad 
d...@virtualized.orgmailto:d...@virtualized.org wrote:

On Oct 23, 2014, at 6:29 AM, Jelte Jansen 
jelte.jan...@sidn.nlmailto:jelte.jan...@sidn.nl wrote:
I do not think putting multiple questions in one request isn't reliably
possible without heavy protocol changes;

I presume you mean is not isn't.  Not sure it would require 'heavy' 
protocol changes -- I suspect all it would take would be to document how the 
multiple questions are packed into the query and how the multiple answers to 
those questions are packed into and parsed from the response. Since the 
question is included in the response, it shouldn't be too hard, just a small 
matter of programming... (:)).

David,

See https://www.ietf.org/mail-archive/web/dnsop/current/msg09457.html

kind regards,

Ray

___
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] DNS namespace collisions and controlled interruption

[Ray Bellis]

On 10 Jan 2014, at 11:28, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 I suspect that, in many cases, the leak comes from systems which are
 not under the direct control of the system administrator.
 
 1) Jane Sysadmin, who works for Acme Corp, decides (wrongly) to use
 .HOME for the local pseudo-TLD of Acme
 
 2) Employees of Acme Corp stores bookmarks in their Web browser, some
 bookmarks include .home/, for instance http://corpinfo.home/
 
 3) Joe Employee goes back home with his laptop or pad and selects the
 wrong bookmark. Bang! A DNS request for corpinfo.home is done (and
 elicits a 127.0.53.53 response to the poor Joe). But Jane Sysadmin
 will never see it or heard about it. Even the NSA, monitoring the root
 name servers, will not know that it is related to Acme.

That's exactly my theory for many of the bad queries to the root, too.

The other source isn't just bookmarks but links exchanged by email with 
references to internal URLs.  It happens here, where we often see links with 
local (unqualified) hostnames instead of FQDNs.

Ray

___
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] Geoff Huston on DNS-over-TCP-only study.

[Ray Bellis]

On 21 Aug 2013, at 11:00, Geoff Huston g...@apnic.net wrote:

 Yes, our goal was to test out the asserting in RFC5966 that: The majority of 
 DNS server operators already support TCP and we wanted to see if we could 
 quantify what that majority actually was.


[I've been on holiday, so apologies for being late to the party]


FWIW, when I wrote that I was mostly considering _authoritative_ servers, 
although I omitted to say so explicitly.

Thanks for running the experiment and writing the report!

kind regards,

Ray

___
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] Who is xn--j1amh.? Well, the general problem...

[Ray Bellis]

On 20 Mar 2013, at 13:35, Jaap Akkerhuis j...@nlnetlabs.nl wrote:

 Whatalways cracks me up on this page is that all IDNs are sorted under the
 X (because of XNN- I assume).

Does a sensible sorting order for characters from different character sets even 
exist?

The only one I can think of is by strict code point value, but then that would 
produce incorrect results for those languages whose own code points aren't in 
lexical order.

Ray


___
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] Who is xn--j1amh.? Well, the general problem... {Sender Address Possibly Forged}

[Ray Bellis]

On 20 Mar 2013, at 14:19, Ray Bellis ray.bel...@nominet.org.uk wrote:

 Does a sensible sorting order for characters from different character sets 
 even exist?
 
 The only one I can think of is by strict code point value, but then that 
 would produce incorrect results for those languages whose own code points 
 aren't in lexical order.

oh, and before anyone else says it (/me waves at Joe!)

s/(language|character set)/script/g

Ray

___
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] DNS TCP performance testing

[Ray Bellis]

On 8 Mar 2013, at 11:21, Wolfgang Nagele wolfgang.nag...@ausregistry.com.au 
wrote:

 Hi,
 
 Any tool recommendations for DNS performance testing when using TCP as a 
 transport? dnsperf and all others I know only do UDP.

I've previously used tcpreplay with the --pps option to replay a real 
stream of pcapped queries at a server and measure the response rate.

Ray

___
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] Capturing 8.8.8.8 Traffic

[Ray Bellis]

On 25 Feb 2013, at 20:11, wbr...@e1b.orgmailto:wbr...@e1b.org wrote:

I'm not a guru on much of the consumer equipment, but what I have seen
allows you to use whatever DNS settings are pushed out by the ISP as part
of DHCP.  Just leave that box ticked and you get the ISP's idea of the
proper DNS settings.

In my experience, many CPE do *not* push out the resolvers received from the 
ISP in their DHCP leases.

Most CPE just push out their LAN address.  Some still do that even if the user 
has hard coded resolvers in the UI configuration which then just get used by 
the CPE as its forwarders.

See http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf.  It's 
over four years old now, but I don't think much has changed since I co-authored 
it.  See also RFC 5625.

Ray

___
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] which software is easier to setup a geo-based dns?

[Ray Bellis]

On 7 Oct 2012, at 18:09, Matthew Ghali mgh...@snark.net wrote:

 To unbias the recommendation a bit more, I agree with Bert. I've used nearly 
 all the servers you mentioned, and built a largish DNS service product around 
 PowerDNS, after looking at my options as well. The one you don't mention is 
 Unbound, but I have zero experience with it, so have no idea if it's even 
 appropriate.


Unbound is a recursive server, not authoritative.  For authoritative the 
equivalent is NSD.

kind regards,

Ray

___
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] query source port 53, was Re: Why would an MTA issue an ANY query instead of an MX query?

[Ray Bellis]

On 13 Jun 2012, at 00:56, Mark Andrews wrote:

 Both firewall configuration are broken.  You don't look at source
 ports if you are offering a service.

Although BIND does drop queries from source port 7 and a couple others... ;-)

Ray

___
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