Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

[Joao Luis Silva Damas]

> On 25 Mar 2021, at 23:36, Paul Vixie  wrote:
> 
> On Wed, Mar 24, 2021 at 11:25:48PM +0100, Florian Weimer wrote:
>>> ...
>> 
>> Proactive fragmentation irrespective of path MTU is required for
>> stateless IPv6 UDP services.  Unlike IPv4, the network does not
>> fragment packets.  So a UDP service has to conservatively fragment
>> around 1200 or so bytes (to account for tunnel overhead).  ...
> 
> 1280 subtracts several hundred bytes from 1500 to allow for tunnel
> overhead.

Actually it doesn’t. The IETF arrived at this number from the other side (small 
values for MTU). See mail at bottom to see just what assumptions went into the 
parameters (1280=1025+256 because IPv4 was 512+64 and IPv6 needed to reduce the 
header overhead below that of IPv4. please…, 9600bps...)

> 1232 subtracts dozens more to allow for IP and UDP headers
> and options.

That is does, unnecessarily. There is, and has been for a while, data out there 
showing bigger numbers are OK (for instance, Google published how they got to 
the size they use on QUIC packets based on traffic they observed arriving at 
their network, a fairly decent piece of data).

> 
> please, nobody, subtract even more. if everyone subtracts a fudge
> factor, forever, we'll eventually run out of payload space, or worse,
> go negative.

:)

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


From owner-i...@sunroof.eng.sun.com   
Thu Nov 13 16:41:01 1997
Received: (from majordomo@localhost)
by sunroof.eng.sun.com  
(8.8.8+Sun.Beta.0/8.8.8) id QAA14339
for ipng-dist; Thu, 13 Nov 1997 16:38:00 -0800 (PST)
Received: from Eng.Sun.COM  (engmail1 [129.146.1.13])
by sunroof.eng.sun.com  
(8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14332
for ; Thu, 13 Nov 1997 16:37:51 -0800 (PST)
Received: from saturn.sun.com  (saturn.EBay.Sun.COM 
 [129.150.69.2])
by Eng.Sun.COM  (SMI-8.6/SMI-5.3) with SMTP id 
QAA28654
for mailto:i...@sunroof.eng.sun.com>>; Thu, 
13 Nov 1997 16:37:48 -0800
Received: from postoffice.cisco.com  
(postoffice.cisco.com  [171.69.200.88])
by saturn.sun.com  (8.8.8/8.8.8) with ESMTP id 
QAA28706
for mailto:i...@sunroof.eng.sun.com>>; Thu, 
13 Nov 1997 16:37:49 -0800 (PST)
Received: from [171.69.199.124] (deering-mac.cisco.com 
 [171.69.199.124]) by postoffice.cisco.com 
 (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20862; 
Thu, 13 Nov 1997 16:37:48 -0800 (PST)
X-Sender: deer...@postoffice.cisco.com 
Message-Id: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Nov 1997 16:37:00 -0800
To: IPng Working Group mailto:i...@sunroof.eng.sun.com>>
From: Steve Deering mailto:deer...@cisco.com>>
Subject: (IPng 4802) increasing the IPv6 minimum MTU
Cc: hin...@ipsilon.com 
Sender: owner-i...@eng.sun.com 
Precedence: bulk

In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU
from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e.,
1500 minus room for a couple layers of encapsulating headers, so that min-
MTU-size packets that are tunneled across 1500-byte-MTU paths won't be
subject to fragmentation/reassembly on ingress/egress from the tunnels,
in most cases).

After the short discussion in the Munich meeting, I called for a show of
hands, and of those who raised their hands (about half the attendees, if
I recall correctly), the vast majority were in favor of this change --
there were only two or three people opposed.  However, we recognized that
a fundamental change of this nature requires thoughtful discussion and
analysis on the mailing list, to allow those who were not at the meeting
and those who were there but who have since had second thoughts, to express
their opinions.  A couple of people have already, in private conversation,
raised some concerns that were not identified in the discussion at the
meeting, which I report below.  We would like to get this issue settled as
soon as possible, since this is the only thing holding up the publication
of the updated Proposed Standard IPv6 spec (the version we expect to advance
to Draft Standard), so let's see if we can come to a decision before the ID
deadline at the end of next week (hoping there isn't any conflict between
"thoughtful analysis" and "let's decide quickly" :-).

The reason I would like to increase the minimum MTU is that there are some
applications for which Path MTU Discovery just won't work very well, 

[dns-operations] Resuming DNS WG monthly sessions

[Joao Luis Silva Damas]

Hi all,

The RIPE DNS WG will be restarting the online sessions starting this Thursday, 
Sept 17th at 15:00 CEST, with two contributions:

DNS Flag Day 2020, Ondřej Surý
Nominet Auth Anycast in the "cloud", Brett Carr

Please come join us on Zoom:

Topic: DNS Working Group - Meeting
Time: Sep 17, 2020 03:00 PM Amsterdam

Join Zoom Meeting
https://ripe.zoom.us/j/99874485118?pwd=T0ZyWjBrWGwwZE12VUZhd1l6Sm5ZQT09

Meeting ID: 998 7448 5118
Passcode: 353222
One tap mobile
+31207946519,,99874485118# Netherlands
+31207946520,,99874485118# Netherlands

Dial by your location
  +31 20 794 6519 Netherlands
  +31 20 794 6520 Netherlands
  +31 20 794 7345 Netherlands
  +31 707 006 526 Netherlands
  +31 20 241 0288 Netherlands
  +31 20 794 0854 Netherlands
  +1 312 626 6799 US (Chicago)
  +1 346 248 7799 US (Houston)
  +1 646 558 8656 US (New York)
  +1 669 900 9128 US (San Jose)
  +1 253 215 8782 US (Tacoma)
  +1 301 715 8592 US (Germantown)
Meeting ID: 998 7448 5118
Find your local number: https://ripe.zoom.us/u/acFqC9I7FN

Join by SIP
99874485...@zoomcrc.com

Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (Amsterdam Netherlands)
213.244.140.110 (Germany)
103.122.166.55 (Australia)
149.137.40.110 (Singapore)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
207.226.132.110 (Japan)
Meeting ID: 998 7448 5118
Passcode: 353222
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Joao Luis Silva Damas]

> On 1 Apr 2020, at 00:24, Denesh Bhabuta via dns-operations 
>  wrote:
> 
> 
> Interestingly enough, the Super 7 - part of the IAO - who ensured web 
> addresses were real... were the main topic in the episode Ill Tidings of 
> Sherlock inspired US TV show Elementary .. I think it was around 4 years ago.

That’s the episode where all of the Super7 die from ingesting poisoned glass 
fibre, right? I will give that plan a pass

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

Re: [dns-operations] Problem with ns.uu.net

[Joao Luis Silva Damas]

all seems to be *almost* good for .ee in ns.uu.net

$ dig @ns.uu.net ee soa

;  DiG 9.9.2-P2  @ns.uu.net ee soa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 27874
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ee.IN  SOA

;; ANSWER SECTION:
ee. 86400   IN  SOA ns.tld.ee. 
hostmaster.eestiinternet.ee. 1370411401 14400 7200 360 10800

;; Query time: 106 msec
;; SERVER: 137.39.1.3#53(137.39.1.3)
;; WHEN: Thu Jun 27 13:26:35 2013
;; MSG SIZE  rcvd: 99

Responds as authoritative but is behind in its SOA

$ dig +nssearch ee
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1372332001 14400 7200 360 10800 
from server 194.146.106.110 in 50 ms.
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1372332001 14400 7200 360 10800 
from server 192.36.125.2 in 56 ms.
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1372332001 14400 7200 360 10800 
from server 193.40.56.245 in 61 ms.
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1372332001 14400 7200 360 10800 
from server 193.40.5.99 in 66 ms.
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1372332001 14400 7200 360 10800 
from server 195.43.87.10 in 77 ms.
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1372332001 14400 7200 360 10800 
from server 213.184.51.122 in 79 ms.
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1372332001 14400 7200 360 10800 
from server 194.204.0.1 in 80 ms.
SOA ns.tld.ee. hostmaster.eestiinternet.ee. 1370411401 14400 7200 360 10800 
from server 137.39.1.3 in 105 ms.

Don't have up to date contacts for Verizon's NOC. try:
 hel...@verizonbusiness.com +1.8009000241  
and see if that helps

Joao

On 27 Jun 2013, at 12:34, Jaana Järve net...@uninet.ee wrote:

 Hello,
 
 is there anybody here who can either confirm or deny that ns.uu.net is not 
 and has not been answering queries about .int or .ee?
 And if it is talking to you, what serial does it give for .ee?
 
 I haven't yet been able to find anyplace I could successfully query it from, 
 although I suppose it has to be working for _some_ zones, for someone or 
 there would be a visible hoopla about it. 
 ___
 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