Re: [dns-operations] [DNSSEC] Venezuela ccTLD broken

[Yasuhiro Orange Morishita / 森下泰宏]

It looks like one of the USGBKR cases...
cf. https://lists.dns-oarc.net/pipermail/dns-operations/2014-March/011399.html

Before: https://dnsviz.net/d/ve/ZLZ8ng/dnssec/
After: https://dnsviz.net/d/ve/ZLjinw/dnssec/

-- Yasuhiro Orange Morishita

From: Stephane Bortzmeyer 
Subject: [dns-operations] [DNSSEC] Venezuela ccTLD broken
Date: Thu, 20 Jul 2023 09:37:10 +0200

> https://dnsviz.net/d/ve/ZLjinw/dnssec/
> 
> The DS goes to a key which does not sign (and there is no DS for the
> key which is actually signing.)
> 
> 
> ___
> 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] Increase in DNS over TCP from Chrome Browser on Windows 11

[Yasuhiro Orange Morishita / 森下泰宏]

Hi,

> Has anyone else seen an increase in DNS over TCP traffic in their
> environment?  We have been seeing a steady increase since late last
> year and have believe we have narrowed down a major cause.  After
> reaching out to the Chromium folks and Cricket Liu reaching out to
> the Microsoft folks it seems that there has been a recent behavior
> change that is incompatible with each other, which is causing DNS
> over TCP to be preferred over UDP.

A few days ago, I saw an issue report from a router vendor that may be
caused by it.  It appears that some CPEs are unable to handle large
amounts of TCP DNS traffic.

Original page, in Japanese:
https://www.aterm.jp/support/tech/2023/0224.html 
Google Translation:
https://www-aterm-jp.translate.goog/support/tech/2023/0224.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=ja&_x_tr_pto=wapp

> Cricket Liu reach out to the Microsoft folks and found that starting
> with Windows 11, the OS began to use socket caching due to
> exhaustion occurring with UDP ports.  Meaning that DNS UDP port is
> cached when communicating with the same server and any DNS client
> will continue to get the same UDP src-port when connecting to that
> DNS server.

IMHO, this Windows 11 behavior seems to contain security risks...

-- Yasuhiro 'Orange' Morishita 

From: Adam Casella 
Subject: Increase in DNS over TCP from Chrome Browser on Windows 11
Date: Tue, 14 Mar 2023 03:57:03 +

> Hey Folks,
> 
> Has anyone else seen an increase in DNS over TCP traffic in their 
> environment?   We have been seeing a steady increase since late last year and 
> have believe we have narrowed down a major cause.   After reaching out to the 
> Chromium folks and Cricket Liu reaching out to the Microsoft folks it seems 
> that there has been a recent behavior change that is incompatible with each 
> other, which is causing DNS over TCP to be preferred over UDP.
> 
> Based on my discussion with the Chromium team, It appears that for about 3 
> years Chrome has a bit of internal logic around falling back to TCP when 
> there is a detection of reduced UDP port entropy being handed out by the OS.  
>  When the Chrome stack falls back to TCP, according to the Chromium folks, it 
> will continue to use TCP until Chrome is restarted or there is a network 
> change (port flap, IP address change, etc).  The code that tracks the low 
> entropy can be found here net::DnsUdpTracker.
> 
> The Chromium folks confirmed that they are seeing an increase of TCP traffic 
> from Windows client only.   Crickey Liu reach out to the Microsoft folks and 
> dfound that starting with Windows 11, the OS began to use socket caching due 
> to exhaustion occurring with UDP ports.  Meaning that DNS UDP port is cached 
> when communicating with the same server and any DNS client will continue to 
> get the same UDP src-port when connecting to that DNS server.   Now starting 
> in Chrome 105, there was a change made by the Chromium folks to leverage the 
> internat Chrome DNS stack to to run more Windows DNS queries through the 
> Chrome stack instead of delegating the resolutions to the OS.   Due to the 
> low UDP port entropy logic discussed above in combination to the socket 
> caching introduced Windows 11,  we are seeing DNS clients preferring TCP over 
> UDP for what seemed like to discernable reason until these discussions with 
> the Chromium and Microsoft folks.
> 
>>From our perspective this is and will cause a lot of issues for DNS providers 
>>as more and more Chrome + Windows clients begin to prefer TCP over UDP for 
>>DNS. And believe this has the potential to quickly become a rather large 
>>issue for DNS providers, especially at scale.
> 
> Is anyone here seeing a seemingly unexplained increase in DNS over TCP 
> traffic and if it is causing any issues within their network?
> 
> For reference, Google Chrome version 105 was released on August 30th, 2022 
> and Windows 11 was released on October 5th, 2021.  Only with the combination 
> of the two (post August 30th, 2022) would the issue be seen.
> 
> Thanks,
> 
> Adam Casella | Solutions Architect
> Infoblox | infoblox.com
> 914.953.8571
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] What is the reason of J-Root doesn't serve the arpa zone?

[Yasuhiro Orange Morishita / 森下泰宏]

Hi Duane-san,

I'm also an Internet old timer, so I know that the root servers also
served com / org / net before.  But I didn't know why J-Root don't
provide arpa zone.  Thank you for your clarification and it is so
interesting.

I tweeted the summary of your explanation in Japanese:
<https://twitter.com/OrangeMorishita/status/1467525559807016960>

And I heard from another person that J-Root holds the arpa zone, but
not delegated.  It is also interesting.

-- Orange

-- 
Yasuhiro 'Orange' Morishita 

From: "Wessels, Duane" 
Subject: Re: [dns-operations] What is the reason of J-Root doesn't serve the 
arpa zone?
Date: Fri, 3 Dec 2021 23:39:48 +

> Thanks for the opportunity to add some clarity around J-root and
> the arpa zone.  Here is a brief history of events that can provide
> some context:
> 
> In the 1996 time frame there were 9 root servers: A through I.  In
> addition to the root zone, they also served a number of TLDs,
> including com, net, org, and arpa.
> 
> It is important to understand that when Jon Postel expanded the
> root servers in 1997 to include J, K, L, and M, the new ones only
> served the root and root-servers.net zones.
> 
> In June 2000 RFC 2870 was published with section 2.5 stating:
> 
>   [root servers] also MUST NOT provide secondary service for
>   any zones other than the root and root-servers.net zones.
> 
> Around this same time (+/- 1 year) the first nine root servers
> stopped serving com, net, and org, but not arpa.
> 
> In November 2002 K, L, and M were added to the NS list for arpa,
> but J was not.  We can't speak to decisions made by the other
> operators, but Verisign chose not to put j.root-servers.net in the
> NS set based on the language of RFC 2870.
> 
> DW
> 
> 
>> On Dec 2, 2021, at 10:08 PM, Yasuhiro Orange Morishita / 森下泰宏 
>>  wrote:
>> 
>> Caution: This email originated from outside the organization. Do not click 
>> links or open attachments unless you recognize the sender and know the 
>> content is safe. 
>> 
>> Hi,
>> 
>> Now I'm writing an article for Japanese people that introduces the
>> IETF's recent DNS-related activities, and I have a question about the
>> current "arpa" zone.
>> 
>> RFC 9120 says:
>> 
>>   Historically, the "arpa" zone has been hosted on almost all of the
>>   root nameservers (NSs), and [RFC3172] envisages the "arpa" domain to
>>   be "sufficiently critical that the operational requirements for the
>>   root servers apply to the operational requirements of the "arpa"
>>   servers".  To date, this has been implemented by serving the "arpa"
>>   domain directly on a subset of the root server infrastructure.
>> 
>> Yes, it is "almost all", not "all".  Currently, the "arpa" zone has
>> been hosted on 12 root servers, except to J-Root.
>> 
>> Probably, this is a part of the "Historically", but I want to know why.
>> 
>> -- Orange
>> 
>> -- 
>> Yasuhiro 'Orange' Morishita 
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://secure-web.cisco.com/1UPWQoE5QZLgSrY5t3Pk7jXYfTh275uVJ8x1xZqeVty8lc-Yaa_VRvU_qscPHa63slHPejQEwqAeGcHQqGLFc8cxEazngQZbzGtRJs-kpGh1Ix2ImAu6_Db9Ei0BEH7ExEYpVkdqdAdQoOhIczU-CA_RzUA5Q2ZcnDm3-NF07D4OKwhGGmE81IOScm_VxTGW5pUfkPp1xa7_aUn26-u0HJ6CCRP33Yi1TAEz0TCAxZtMHo4t0TVlG9rqLS6IBN0is8o8vD9eZMN5UAsokuWH72Q/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations
>> 
> 
> 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] What is the reason of J-Root doesn't serve the arpa zone?

[Yasuhiro Orange Morishita / 森下泰宏]

Hi,

Now I'm writing an article for Japanese people that introduces the
IETF's recent DNS-related activities, and I have a question about the
current "arpa" zone.

RFC 9120 says:

   Historically, the "arpa" zone has been hosted on almost all of the
   root nameservers (NSs), and [RFC3172] envisages the "arpa" domain to
   be "sufficiently critical that the operational requirements for the
   root servers apply to the operational requirements of the "arpa"
   servers".  To date, this has been implemented by serving the "arpa"
   domain directly on a subset of the root server infrastructure.

Yes, it is "almost all", not "all".  Currently, the "arpa" zone has
been hosted on 12 root servers, except to J-Root.

Probably, this is a part of the "Historically", but I want to know why.

-- Orange

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

Re: [dns-operations] dnspooq

[Yasuhiro Orange Morishita / 森下泰宏]

Ralph-san,

> The DNS forwarders term didn’t appear in an RFC before 7719, so I guess
> there is no such description.

As described in RFC 8499, "forwarder" was first appeared and defined
in RFC 2308, but it describes "a nameserver used to resolve queries
instead of directly using the authoritative nameserver chain"..

Anyway, I agree that no such description for the behavior of DNS
forwarders.

-- Orange

From: "Ralf Weber" 
Subject: Re: [dns-operations] dnspooq
Date: Thu, 21 Jan 2021 14:15:16 +0100

> Moin!
> 
> On 21 Jan 2021, at 13:48, Yasuhiro Orange Morishita / 森下泰宏 wrote:
>> I know that section 6 of RFC 5452 describes 'in-domain checking'
>> for full-service resolvers, but I can't find any RFCs describing the
>> same checking for DNS forwarders...
> The DNS forwarders term didn’t appear in an RFC before 7719, so I guess
> there is no such description.
> 
>> Moreover, the whitepaper describes this as follows:
>>
>>   "We acknowledge that this is not a vulnerability per se, and
>>   moreover is reasonable behavior, though it magnifies the attack and
>>   similar types of attacks."
>>
>> Isn't it really a vulnerability?
> I agree for a real DNS forwarder (aka proper resolver acting as a
> forwarder), but for a DNS proxy there really is no other option then
> to give the packet back to the client (stub resolver) and let it deal
> with it.
> 
> So long
> -Ralf
> ――-
> Ralf Weber
> 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] dnspooq

[Yasuhiro Orange Morishita / 森下泰宏]

Hi,

> fyi
> https://www.jsof-tech.com/disclosures/dnspooq/

I've read a technical whitepaper of the DNSpooq[*1] from JSOF,
and I have a question about response validation in DNS forwarders.

[*1] DNSpooq - Cache Poisoning and RCE in Popular DNS Forwarder dnsmasq
 

Section 3.4 of the whitepaper describes dnsmasq doesn't perform the
'in-domain' check, and dnsmasq accepts the following answer (and
overwrite an existing cache of www.bank.com) from upstream
full-service resolver.

  ;; ANSWER SECTION:
  www.example.com. IN CNAME www.bank.com.
  www.bank.com.IN A 6.6.6.6

I know that section 6 of RFC 5452 describes 'in-domain checking'
for full-service resolvers, but I can't find any RFCs describing the
same checking for DNS forwarders...

Moreover, the whitepaper describes this as follows:

  "We acknowledge that this is not a vulnerability per se, and
  moreover is reasonable behavior, though it magnifies the attack and
  similar types of attacks."

Isn't it really a vulnerability?

-- Orange

From: FUSTE Emmanuel 
Subject: Re: [dns-operations] dnspooq
Date: Thu, 21 Jan 2021 11:29:16 +

> Le 21/01/2021 à 12:07, Stephane Bortzmeyer a écrit :
>> On Tue, Jan 19, 2021 at 03:53:04PM +,
>>   Roy Arends  wrote
>>   a message of 7 lines which said:
>>
>>> fyi
>>>
>>> https://www.jsof-tech.com/disclosures/dnspooq/
>> Real vulnerabilities and good technical work but why do they feel the
>> need to add references to the "Internet DNS Architecture" (it is not a
>> DNS problem, purely bugs in an implementation) or to HSTS (what's its
>> relationship with a bug in a DNS program?)?
>>
>> To get more attention?
>>
> Yes I stop reading past this. Very bad editorial choice in my opinion.
> But sadly the modern/actual way of informing: sensationalism, up to the 
> border of the fake.
> 
> Emmanuel.
> 
> ___
> 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] DNS attacks against FR/BE/NL resolvers of Internet access providers

[Yasuhiro Orange Morishita / 森下泰宏]

Hi Stephane-san,

I've read the article.  I am suspecting the attack vector is random
subdomain attacks via bad CPEs, they acts open resolvers and
forwarding queries to ISP's resolvers.

Possibly, the real target domain name was exist and the attackers
tried to down the auth servers of the domain.

-- Orange

From: Stephane Bortzmeyer 
Subject: [dns-operations] DNS attacks against FR/BE/NL resolvers of Internet 
access providers
Date: Mon, 14 Sep 2020 15:14:59 +0200

> On 1 and 2 September 2020, several French IAPs (Internet Access
> Providers), including SFR and Bouygues, were "down". Their DNS
> resolvers were offline, and it does indeed seem that this was the
> result of an attack carried out against these resolvers.
> 
> https://www.afnic.fr/en/resources/blog/about-the-attack-on-french-isps-dns-resolvers.html
> 
> ___
> 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] DNS Flag Day 2020 will become effective on 2020-10-01

[Yasuhiro Orange Morishita / 森下泰宏]

Hi Petr-san,

I tested some auth servers and resolvers by online checker in the
official website.

But I feel that both of them display "GO" even if EDNS buffer size is
not set to 1232.  Is this by design?

-- Orange

From: Petr Špaček 
Subject: [dns-operations] DNS Flag Day 2020 will become effective on 2020-10-01
Date: Tue, 8 Sep 2020 12:04:39 +0200

> Dear DNS people.
> 
> We are happy to announce next step for DNS Flag Day 2020.
> 
> Latest measurements indicate that practical breakage caused by the proposed 
> change is tiny [1]. In other words we can conclude that the Internet is ready 
> for the change.
> 
> The long delayed DNS Flag Day will become effective on 2020-10-01 (October 
> 1st 2020)!
> 
> Detailed information including test tools and technical description of the 
> change can be found at https://dnsflagday.net/2020/ .
> 
> For questions please use dns-operations@lists.dns-oarc.net mailing list.
> 
> [1] 
> https://github.com/dns-violations/dnsflagday/issues/139#issuecomment-673489183
> 
> -- 
> Petr Špaček  @  CZ.NIC
> ___
> 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 behavior of covid.cdc.gov

[Yasuhiro Orange Morishita / 森下泰宏]

Mark-san,

> Thankfully cdc.gov is also served by auth00.ns.uu.net and auth100.ns.uu.net
> and they aren’t serving a incomplete version of akam.cdc.gov.

Certainly, cdc.gov has 5 NSes.  And both uu.net servers return correct
answer for covid.cdc.gov/A query.

I added two dig outputs into my text, thank you.
<https://www.dropbox.com/s/alfb1ftvzpd6qcv/20200831-covid.cdc.gov.txt>

I think this case is so curious and these digs should be preserved,
like an appldnld's case.
<https://www.dropbox.com/s/nvw46gtxupggo1e/20120314-appldnld.apple.com.txt>

-- Orange

From: Mark Andrews 
Subject: Re: [dns-operations] Strange behavior of covid.cdc.gov
Date: Tue, 1 Sep 2020 14:22:16 +1000

> Thankfully cdc.gov is also served by auth00.ns.uu.net and auth100.ns.uu.net
> and they aren’t serving a incomplete version of akam.cdc.gov.  Recursive
> servers will eventually get a valid referral rather than bogus (unsigned)
> answers from ns[123].cdc.gov for akam.cdc.gov.
> 
> Mark
> 
>> On 1 Sep 2020, at 00:47, Stephane Bortzmeyer  wrote:
>> 
>> On Mon, Aug 31, 2020 at 10:12:04PM +0900,
>> Yasuhiro Orange Morishita / 森下泰宏  wrote 
>> a message of 18 lines which said:
>> 
>>> But it seems to be a little bit strange.  The auth servers of cdc.gov
>>> zone serve unneed (and unsigned) akam.cdc.gov zone.  But they still
>>> have DS RR for real akam.cdc.gov zone.
>> 
>> They also do not return a proper delegation:
>> 
>> % dig +dnssec +norec @icdc-us-ns2.cdc.gov. A akam.cdc.gov 
>> ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec 
>> @icdc-us-ns2.cdc.gov. A akam.cdc.gov
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43497
>> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ; COOKIE: 70d47b392dfb22d2662352815f4d0d3fe1c90df99f508386 (good)
>> ;; QUESTION SECTION:
>> ;akam.cdc.gov.   IN A
>> 
>> ;; AUTHORITY SECTION:
>> akam.cdc.gov.3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. (
>>  612558384  ; serial
>>  300; refresh (5 minutes)
>>  180; retry (3 minutes)
>>  1209600; expire (2 weeks)
>>  3600   ; minimum (1 hour)
>>  )
>> 
>> ;; Query time: 98 msec
>> ;; SERVER: 198.246.96.92#53(198.246.96.92)
>> ;; WHEN: Mon Aug 31 16:46:23 CEST 2020
>> ;; MSG SIZE  rcvd: 129
>> 
>> % dig +dnssec +norec @icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov
>> ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec 
>> @icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44336
>> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ; COOKIE: 2e27a9b171983390a21696a65f4d0d54710de953e8dd107b (good)
>> ;; QUESTION SECTION:
>> ;akam.cdc.gov.   IN DNSKEY
>> 
>> ;; AUTHORITY SECTION:
>> akam.cdc.gov.3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. (
>>  612558384  ; serial
>>  300; refresh (5 minutes)
>>  180; retry (3 minutes)
>>  1209600; expire (2 weeks)
>>  3600   ; minimum (1 hour)
>>  )
>> 
>> ;; Query time: 98 msec
>> ;; SERVER: 198.246.96.92#53(198.246.96.92)
>> ;; WHEN: Mon Aug 31 16:46:44 CEST 2020
>> ;; MSG SIZE  rcvd: 129
>> 
>> Whuch may explain the strange error messages of DNSviz (the IP
>> addresses are for the parent zone).
>> ___
>> 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

[dns-operations] Strange behavior of covid.cdc.gov

[Yasuhiro Orange Morishita / 森下泰宏]

Hi,

Now covid.cdc.gov seems to be DNSSEC validation error.
Google Public DNS and some DNSSEC-enabled resolvers return SERVFAIL.
e.g. dig covid.cdc.gov @8.8.8.8

But it seems to be a little bit strange.  The auth servers of cdc.gov
zone serve unneed (and unsigned) akam.cdc.gov zone.  But they still
have DS RR for real akam.cdc.gov zone.

This is output of digs.


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

Re: [dns-operations] DNS-OARC's Web-based DNS Randomness Test site

[Yasuhiro Orange Morishita / 森下泰宏]

Keith-san,

Thank you for your reply and explanation.
I hope that upcoming workshop is successfully held, and I will
continue about this issue on ad...@dns-oarc.net.

-- Orange

--
Yasuhiro 'Orange' Morishita yasuh...@jprs.co.jp

From: Keith Mitchell ke...@dns-oarc.net
Date: Thu, 09 Oct 2014 08:59:56 -0400

 On 10/09/2014 07:32 AM, Yasuhiro Orange Morishita wrote:
 
  Now DNS-OARC's Web-based DNS Randomness Test site doesn't work properly...
  Is this service closed?
 
 No, this service is still supported, though note that there have been a
 number of exploits published since this test was derived which means
 that results previously stated as safe are now less clear-cut.
 
 For questions/issues with OARC services, the best place to request help
 is ad...@dns-oarc.net.
 
 We will investigate, though this may take a little longer than usual due
 to the upcoming workshop and planned systems maintenance over the next
 few days.
 
 Keith
 
 
 
  Web-based DNS Randomness Test
  http://entropy.dns-oarc.net/
  (redirected to https://www.dns-oarc.net/oarc/services/dnsentropy)
  
  txt (dig/drill) version seems to be OK,
  but web version is better for plenty of users.
  
  % dig +short porttest.dns-oarc.net txt
  porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
  xxx.xxx.xxx.xxx is GREAT: 26 queries in 2.7 seconds from 26 ports with std 
  dev 17312
 
___
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-operations Digest, Vol 92, Issue 13

[Yasuhiro Orange Morishita / 森下泰宏]

 And I know the IP specification defines the minimal MTU size to 576.
 So, we may need a very short RFC for updating the definition of MTU,
 ^
to 1280

-- Orange

 in RFC 791.

From: Yasuhiro Orange Morishita / 森下泰宏 yasuh...@jprs.co.jp
Date: Wed, 11 Sep 2013 02:02:34 +0900 (JST)

 Paul-san,
 
  for unsigned responses, i think a v6 max-udp-size of 1220 and a v4
  max-udp-size of 512 is what's called for.
 
 I believe typical datalinks of MTU=576 are (were) X.25 and SLIP
 (Of course, it's not RRL's one).  And I believe both links are deprecated.
 
 And I know the IP specification defines the minimal MTU size to 576.
 So, we may need a very short RFC for updating the definition of MTU,
 in RFC 791.
 
 -- Orange
 
 From: Paul Vixie p...@redbarn.org
 Date: Mon, 09 Sep 2013 07:31:42 -0700
 
  ...
  
  Yasuhiro Orange Morishita / 森下泰宏 wrote:
   Paul-san, and folks,
  
   Now we (including me) have known the dangers and limitations,
   so should we set max-udp-size to 1220 on every authoritative servers?
  
  for unsigned responses, i think a v6 max-udp-size of 1220 and a v4 
  max-udp-size of 512 is what's called for. i've not seen an explanation of 
  how dnssec-covered data can be poisoned, even with fragment attacks. 
  orange, can you write RFC 6891-bis?
  
  the messaging that would go out with this is, everybody needs to sign their 
  dns data, and everybody needs to validate, and if you're planning to send 
  large responses then your authority servers must be v6 reachable, and your 
  v4 performance will be low due to tcp.
  
  vixie
  
 ___
 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
 
___
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-operations Digest, Vol 92, Issue 13

[Yasuhiro Orange Morishita / 森下泰宏]

Paul-san,

 for unsigned responses, i think a v6 max-udp-size of 1220 and a v4
 max-udp-size of 512 is what's called for.

I believe typical datalinks of MTU=576 are (were) X.25 and SLIP
(Of course, it's not RRL's one).  And I believe both links are deprecated.

And I know the IP specification defines the minimal MTU size to 576.
So, we may need a very short RFC for updating the definition of MTU,
in RFC 791.

-- Orange

From: Paul Vixie p...@redbarn.org
Date: Mon, 09 Sep 2013 07:31:42 -0700

 ...
 
 Yasuhiro Orange Morishita / 森下泰宏 wrote:
  Paul-san, and folks,
 
  Now we (including me) have known the dangers and limitations,
  so should we set max-udp-size to 1220 on every authoritative servers?
 
 for unsigned responses, i think a v6 max-udp-size of 1220 and a v4 
 max-udp-size of 512 is what's called for. i've not seen an explanation of how 
 dnssec-covered data can be poisoned, even with fragment attacks. orange, can 
 you write RFC 6891-bis?
 
 the messaging that would go out with this is, everybody needs to sign their 
 dns data, and everybody needs to validate, and if you're planning to send 
 large responses then your authority servers must be v6 reachable, and your v4 
 performance will be low due to tcp.
 
 vixie
 
___
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-operations Digest, Vol 92, Issue 13

[Yasuhiro Orange Morishita / 森下泰宏]

Paul-san, and folks,

Now we (including me) have known the dangers and limitations,
so should we set max-udp-size to 1220 on every authoritative servers?

-- Orange

From: Paul Vixie p...@redbarn.org
Date: Mon, 09 Sep 2013 04:47:44 -0700

 regrettably, the author of RFC 2671 knew the dangers and limitations of
 fragmented IP, but specified it anyway.
 
 see especially: http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html
 
 (where the authors of WRL-87-3 were two early mentors of the later
 author of RFC 2671, who not only ought to have, but did, know better.)
 
 vixie
 
 re:
 
 Haya Shulman wrote:
  Yasuhiro-san :-)
 
  Nice find, thanks for sharing!!
  I will add reference to it in our works.
 
  On Sun, Sep 8, 2013 at 3:00 PM,
  dns-operations-requ...@lists.dns-oarc.net
  mailto:dns-operations-requ...@lists.dns-oarc.net wrote:
 
 
 
  Message: 6
  Date: Sun, 08 Sep 2013 tel:2013 17:30:57 +0900 (JST)
  From: Yasuhiro Orange Morishita /   yasuh...@jprs.co.jp
  mailto:yasuh...@jprs.co.jp
  To: aa...@arbor.net mailto:aa...@arbor.net
  Cc: dns-operati...@mail.dns-oarc.net
  mailto:dns-operati...@mail.dns-oarc.net, edmo...@mycre.ws
  mailto:edmo...@mycre.ws
  Subject: Re: [dns-operations] DNS Attack over UDP fragmentation
  Message-ID: 20130908.173057.37558842.yasuh...@jprs.co.jp
  mailto:20130908.173057.37558842.yasuh...@jprs.co.jp
  Content-Type: Text/Plain; charset=utf-8
 
  Aaron-san, Haya-san, and folks,
 
  I've found the following RFC, it's published in 2007 tel:2007.
 
RFC 4963 tel:4963 - IPv4 Reassembly Errors at High Data Rates
http://tools.ietf.org/html/rfc4963
 
  And I've cited Security Considerations of this RFC as below:
 
  BTW, When the RFC was I-D, it's titled IPv4 Fragmentation Considered
  Very Harmful.
 
http://tools.ietf.org/html/draft-heffner-frag-harmful-03
 
  So, we should have been discussing this issue before DNSSEC
  deployment.
 
  -- Orange
 
  ---
  7. Security Considerations
 
 If a malicious entity knows that a pair of hosts are communicating
 using a fragmented stream, it may be presented with an
  opportunity to
 corrupt the flow.  By sending high fragments (those with offset
 greater than zero) with a forged source address, the attacker can
 deliberately cause corruption as described above.  Exploiting this
 vulnerability requires only knowledge of the source and destination
 addresses of the flow, its protocol number, and fragment
  boundaries.
 It does not require knowledge of port or sequence numbers.
 
 If the attacker has visibility of packets on the path, the attack
 profile is similar to injecting full segments.  Using this attack
 makes blind disruptions easier and might possibly be used to cause
 degradation of service.  We believe only streams using IPv4
 fragmentation are likely vulnerable.  Because of the nature of the
 problems outlined in this document, the use of IPv4
  fragmentation for
 critical applications may not be advisable, regardless of security
 concerns.
  ---
 
 
  From: Aaron Campbell aa...@arbor.net mailto:aa...@arbor.net
  Date: Sat, 7 Sep 2013 tel:2013 08:27:47 -0300
 
   On 2013-09-06, at 1:42 PM, Robert Edmonds edmo...@mycre.ws
  mailto:edmo...@mycre.ws wrote:
  
Aaron Campbell wrote:
Here is a thought, but I will defer to the protocol experts
  on plausibility.  The resolver knows the size of each DNS message
  it parses.  What if it didn't trust glue records contained within
  large (i.e.,  1400 bytes or so) responses?  In these cases, the
  resolver sends a separate query to resolve the dangling authority
  NS records.  This introduces overhead, but only for large replies.
   It also makes a few assumptions, namely that the fragmentation
  point is something around 1500 bytes (and not something lower),
  and that the attack is only practical against the glue records,
  not the authority section.  May be able to play games with name
  compression there though? perhaps it is as least worth discussing
  as an additional barrier.
   
this sounds vaguely similar to unbound's
  harden-referral-path option,
though it applies to all lookups.
  
  
   I researched this, and found that it was first described here:
  
  
  
  http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01#section-3.3
  
   The option is currently marked experimental due to not being
  RFC standard, and performance concerns.  If the option were
  applied only to large responses (specifically to mitigate this
  type of attack), that would reduce the performance impact.
  
   -Aaron
   ___
  

Re: [dns-operations] DNS Attack over UDP fragmentation

[Yasuhiro Orange Morishita / 森下泰宏]

Hello,

I believe that it is another serious attack against DNS protocol,
or it may be against UDP/IP (especially IPv4).

So, we might set max-udp-size to 1220 for preventing UDP fragmentation.  
And I know anouther IPv6 Fragment Header Deprecated I-D at IETF 6man WG.

BTW, sometimes I unofficially call the method as DNS Aikora Kougeki
in Japanese.  Kougeki means attacks and Aikora is Japanese slang,
and it's described here.

http://japanslangdictionary.appspot.com/cont?key=ikora

Regards,

-- Orange

From: Ondřej Surý ondrej.s...@nic.cz
Date: Wed, 4 Sep 2013 15:08:55 +0200

 Hi all,
 
 for all those who haven't been on saag WG at IETF 88...
 
 Amir Herzbert and Haya Shulman has presented a quite interesting attack on 
 UDP fragmentation that allows Kaminsky-style attacks to be real again.
 
 The saag presentation is here: 
 http://www.ietf.org/proceedings/87/slides/slides-87-saag-3.pdf
 
 The paper describing the attack is here:
 http://arxiv.org/pdf/1205.4011v1.pdf
 
 More Haya Shulman's publications can be found here:
 https://sites.google.com/site/hayashulman/publications
 
 And some papers are also available from Google Scholar:
 http://scholar.google.com/scholar?hl=enq=Amir+Herzberg%2C+Haya+Shulman+++dnssecbtnG=as_sdt=1%2C5as_sdtp=
 
 We gave it some thoughts here at CZ.NIC Labs and we think that the threat is 
 real and we are now trying to write a PoC code to prove the theoretical 
 concept.
 
 So what are the views of other people on this list?
 
 Ondrej
 --
  Ondřej Surý -- Chief Science Officer
  ---
  CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:ondrej.s...@nic.czhttp://nic.cz/
  tel:+420.222745110   fax:+420.222745112
  ---
 
___
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.

[Yasuhiro Orange Morishita / 森下泰宏]

Geoff's original article is here (in potaroo.net)

A Question of DNS Protocols
http://www.potaroo.net/ispcol/2013-09/dnstcp.html

It also describes the open resolver project as a name and shame approach.
(I have quoted below, and IMHO, certainly this approach is effective)

 The open resolver project is working on a name and shame approach
 to the problem, and is hopeful that by allowing individual resolver
 operators to check their own status, that these resolvers will be
 closed down.

-- Orange

From: Dobbins, Roland rdobb...@arbor.net
Date: Wed, 21 Aug 2013 04:41:49 +
 
 http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/
 
 ---
 Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
 
 Luck is the residue of opportunity and design.
 
  -- John Milton
 
 ___
 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
 
___
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] .biz DNSSEC failure?

[Yasuhiro Orange Morishita / 森下泰宏]

 So, this means that we can not be black history our DNSSEC errors. :-(

Should be dark history.  My English is still poor.

-- Yasuhiro Orange Morishita

From: Yasuhiro Orange Morishita yasuh...@jprs.co.jp
Date: Mon, 24 Jun 2013 19:22:25 +0900 (JST)

 Hi Stephane;
 
  A personal opinion: when posting DNSviz URLs, always attach a screen
  shot of the *current* state. When I've read your message, it was too
  late, .biz was fixed.
 
 Just FYI, DNSviz provides the permanent link. And Previous analysis
 and Next analysis links may provide the error state of specified
 name.
 
 Updated: 2013-06-22 20:15:00 UTC (a day ago)
 http://dnsviz.net/d/biz/UcYFxQ/dnssec/
 
 So, this means that we can not be black history our DNSSEC errors. :-(
 
 I learned this from Daisuke HIGASHI, thank you.
 
 -- Yasuhiro Orange Morishita
 
 From: Stephane Bortzmeyer bortzme...@nic.fr
 Date: Mon, 24 Jun 2013 12:02:31 +0200
 
  On Sat, Jun 22, 2013 at 02:46:56PM -0400,
   staticsafe m...@staticsafe.ca wrote 
   a message of 33 lines which said:
  
   http://dnsviz.net/d/nic.biz/dnssec/
  
  A personal opinion: when posting DNSviz URLs, always attach a screen
  shot of the *current* state. When I've read your message, it was too
  late, .biz was fixed.
  ___
  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
  
 
___
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] Question about L-Root IP address

[Yasuhiro Orange Morishita / 森下泰宏]

Peter-san:

I remember the official debut date of M-Root is Aug 22, 1997.
In the root hint file:
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/namedb/root.cache.diff?r1=1.7r2=1.8

Kato-san's thesis described the same date. (caution: it's written in Japanese)
http://www.nic.ad.jp/ja/materials/iw/1997/proceedings/IPM-PDF/kato.pdf

And now, I'm a little bit confused.
Is your SOA# is root-servers.net's maybe?

-- Orange

From: Peter Koch p...@denic.de
Date: Fri, 28 Dec 2012 08:47:58 +0100

 Hi Orange,
 
  I checked the past root hint file in Aug 22 1997,
  https://lists.isc.org/pipermail/bind-users/2003-January/044241.html
  But its L-Root address is 198.32.64.12, I think it was used until 2007.
 
 L was introduced (together with M) with SOA# 1997031300
 
 . 518400 NSL.ROOT-SERVERS.NET.
 L.ROOT-SERVERS.NET.   518400 A 192.0.5.12
 
 The address was first changed between 1998020200 and 1998020400
 
 -L.ROOT-SERVERS.NET.   518400 A 192.0.5.12
 +L.ROOT-SERVERS.NET.   518400 A 198.32.64.12
 
 Then again between 2007103101 and 2007110100
 
 -L.ROOT-SERVERS.NET. A 198.32.64.12
 +L.ROOT-SERVERS.NET. A 199.7.83.42
 
 -Peter
 
___
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

[dns-operations] Question about L-Root IP address

[Yasuhiro Orange Morishita / 森下泰宏]

Hello, DNS operators:

I found the following description in Peter and Matt's I-D.

It describes IP address changes of L-Root was twice.  But I couldn't
find only once, in 2007.

I checked the past root hint file in Aug 22 1997,
https://lists.isc.org/pipermail/bind-users/2003-January/044241.html
But its L-Root address is 198.32.64.12, I think it was used until 2007.

If you know the information about it, please let me know.

--
Yasuhiro 'Orange' Morishita yasuh...@jprs.co.jp
Japan Registry Services Co., Ltd. (JPRS)


Initializing a DNS Resolver with Priming Queries
http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-02

   The list of root name servers has been rather stable over the last
   ten years.  After the last four servers had been added and moved to
   their final (network) destinations in 1997, there have been only four
   address changes affecting the L (twice), J, and B servers.  Research
   is available for B [Mann2006] and J [BLKT2004], which shows that
   several months or even years after the change had become effective,
   traffic is still received on the old addresses.  Therefore, it is
   important that resolvers be able to cope with change, even without
   relying upon configuration updates to be applied by their operator.
___
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] Advisory — D-root is changing its IPv4 address on the 3rd of January.

[Yasuhiro Orange Morishita / 森下泰宏]

Hello, Jason-san,

This is Yasuhiro Orange Morishita at JPRS.

Thank you for your advance notice.  We will make an announcement the
information for Japanese Internet community.

And if you also publish the information at D-root webpage
http://d.root-servers.org/, I would appreciate.

--
Yasuhiro 'Orange' Morishita yasuh...@jprs.co.jp
Japan Registry Services Co., Ltd. (JPRS)
URI: http://jprs.co.jp/en/ | http://www.dns.jp/

From: Jason Castonguay casto...@umd.edu
Date: Thu, 13 Dec 2012 17:54:41 -0500

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Advisory — D-root is changing its IPv4 address on the 3rd of January.
 
 
 This is advance notice that there is a scheduled change to the IPv4
 address for one of the authorities listed for the DNS root zone and
 the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is
 administered by the University of Maryland.
 
 The new IPv4 address for this authority is 199.7.91.13
 
 The current IPv6 address for this authority is  2001:500:2d::d and it
 will continue to remain unchanged.
 
 This change is anticipated to be implemented in the root zone on 3
 January 2013, however the new address is currently operational. It
 will replace the previous IP address of 128.8.10.90 (also once known
 as TERP.UMD.EDU).
 
 We encourage operators of DNS infrastructure to update any references
 to the old IP address, and replace it with the new address. In
 particular, many DNS resolvers have a DNS root “hints” file. This
 should be updated with the new IP address.
 
 New hints files will be available at the following URLs once the
 change has been formally executed:
 
 http://www.internic.net/domain/named.root
 
 http://www.internic.net/domain/named.cache
 
 The old address will continue to work for at least six months after
 the transition, but will ultimately be retired from service.
 
 - -- 
 Jason Castonguay
 
 Network Integration Software Engineer
 Division of Information Technology
 University of Maryland
 College Park, MD 20742
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with undefined - http://www.enigmail.net/
 
 iEYEARECAAYFAlDKXLEACgkQA5NiLuECHn4lRQCgoOlYQhq+kXk2Az3nPeN1hUfz
 0e4AoKCwp0cLpABJFc/7RV5E/ecfWwoJ
 =ktnM
 -END PGP SIGNATURE-
 ___
 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
 
___
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

[dns-operations] verisigninc.com

[Yasuhiro Orange Morishita / 森下泰宏]

% dig +dnssec www.verisigninc.com a

It returns SERVFAIL now...

http://dnsviz.net/d/www.verisigninc.com/dnssec/
 
 verisigninc.com/DNSKEY: DS RRs exist for algorithm(s) 8 in the com
 zone, but no matching DNSKEYs of algorithm(s) 8 were used to sign
 the verisigninc.com DNSKEY RRset.

-- Yasuhiro 'Orange' Morishita yasuh...@jprs.co.jp
___
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