On Fri, May 8, 2015 at 3:40 PM, Simon Kelley wrote:
> On 07/05/15 16:51, Nicholas Weaver wrote:
>> One important consideration: The Internet has decreed a long time
>> ago that fragments don't work for IPv4, and REALLY don't work for
>> IPv6: the amount of systems that drop fragments for V6 is of
On 08/05/15 16:52, Loganaden Velvindron wrote:
> On Fri, May 8, 2015 at 3:40 PM, Simon Kelley wrote:
>> On 07/05/15 16:51, Nicholas Weaver wrote:
>>> One important consideration: The Internet has decreed a long time
>>> ago that fragments don't work for IPv4, and REALLY don't work for
>>> IPv6: t
Forwarding something from a parallel conversation to the list.
Simon.
Forwarded Message
Subject: Re: testing edns0 on bind
Date: Thu, 7 May 2015 09:58:56 -0700
From: Evan Hunt
To: Simon Kelley
CC: Dave Taht , Toke Høiland-Jørgensen
> This is my hypothesis, which fits what
On 07/05/15 16:51, Nicholas Weaver wrote:
> One important consideration: The Internet has decreed a long time
> ago that fragments don't work for IPv4, and REALLY don't work for
> IPv6: the amount of systems that drop fragments for V6 is off the
> chart.
>
> For DNS, this means you get silent
One important consideration: The Internet has decreed a long time ago that
fragments don't work for IPv4, and REALLY don't work for IPv6: the amount of
systems that drop fragments for V6 is off the chart.
For DNS, this means you get silent failures when the reply is bigger than the
network's M
on a comcast native ipv6 connection, 1232 from OSX (ping6 -s 1232
2001:4860:4860::)
On the router *itself* I can't even
ping6 -s 80 2001:4860:4860::
PING 2001:4860:4860:: (2001:4860:4860::): 80 data bytes
^C
--- 2001:4860:4860:: ping statistics ---
1 packets transmitted,
On 07/05/2015 13:54, Simon Kelley wrote:
> On 07/05/15 10:41, Toke Høiland-Jørgensen wrote:
>> Simon Kelley writes:
>>
>>> It's difficult to see how that would work in practise for DNS. Take
>>> the Google-public-DNS example. It's clearly not sane for Google's
>>> servers to do PMTU on the address
Simon Kelley writes:
> But if they fragment, what size should they fragment to? I guess inthe
> absence of any information to the contrary, 1280 bytes.
Yes, I would think so. Also, the RFC has this to say about the size of
the packets pre-fragmentation:
A node must be able to accept a fragme
Using ping6 2001:4860:4860:: -s
(that's the Google public DNS server)
I see answers up to packet size 1344.
It would be very interesting to know if others see the same (ie it's a
property of the server) or different (it's a property of the link).
Unfortunately, this only tells us about th
Simon Kelley writes:
> Using ping6 2001:4860:4860:: -s
>
> (that's the Google public DNS server)
>
> I see answers up to packet size 1344.
I get answers up to -s 1432. This is on an he.net tunnel.
-Toke
___
Dnsmasq-discuss mailing list
Dnsmasq-d
On 07/05/15 10:41, Toke Høiland-Jørgensen wrote:
> Simon Kelley writes:
>
>> It's difficult to see how that would work in practise for DNS. Take
>> the Google-public-DNS example. It's clearly not sane for Google's
>> servers to do PMTU on the address of every client, just to send one
>> UDP packe
Simon Kelley writes:
> It's difficult to see how that would work in practise for DNS. Take
> the Google-public-DNS example. It's clearly not sane for Google's
> servers to do PMTU on the address of every client, just to send one
> UDP packet, and caching PMTU for clients is going to get hard, fas
On 06/05/15 23:12, Toke Høiland-Jørgensen wrote:
> Simon Kelley writes:
>
>> The MTU if the SIXXs IPv6 network interface is 1428. Failure to
>> receive UDP packets larger than the MTU is a bigger bug than DNS, but
>> I don't know if it's a SIXXS problem or a wider IPv6 one.
>
> Well, IPv6 doesn'
Yes, I was using comcast native ipv6.
On Wed, May 6, 2015 at 1:49 PM, Simon Kelley wrote:
> This stuff does worry me. It's a big source of brittleness.
>
> One thing that's worth pointing out is that it's not necessarily the
> answer to the original query that's too big, it might be the answer to
Simon Kelley writes:
> The MTU if the SIXXs IPv6 network interface is 1428. Failure to
> receive UDP packets larger than the MTU is a bigger bug than DNS, but
> I don't know if it's a SIXXS problem or a wider IPv6 one.
Well, IPv6 doesn't fragment packets; hosts are supposed to do PMTU
discovery
I can demonstrate that there's a problem here, independent of dnsmasq
srk@holly:~$ dig @2001:4860:4860:: dnskey org +dnssec
; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> @2001:4860:4860:: dnskey org
+dnssec
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be
> All the above is on IPv4. Dave are you using IPv6? I'll try that next.
Right, using a SIXXS tunnel, I never see a reply to the query for DNSKEY
org query. Presumably something in the IPv6 connection is failing to do
fragmentation/reassembly. The dig times out without an answer.
Dropping edns
This stuff does worry me. It's a big source of brittleness.
One thing that's worth pointing out is that it's not necessarily the
answer to the original query that's too big, it might be the answer to
one of the DS or DNSKEY queries needed to validate it. If the answer to
one of those comes back wi
Continues to work here on my iPhone hiding behind openwrt cc trunk
dnsmasq2.73rc7
Were I not on the iPhone I could do some dig'age :-)
--
Cheers,
ke...@darbyshire-bryant.me.uk
Sent from my phone, apologies for brevity, spelling & top posting
> On 6 May 2015, at 20:21, Dave Taht wrote:
>
> ns
prematurely sent that email. setting edns_packet_max to 1200 made it
drop to tcp and work.
I am going to argue that edns0 should be set to the bare minimum, by
default, in dnsmasq, whatever it is, for it to
fall back to tcp correctly.
On Wed, May 6, 2015 at 12:09 PM, Dave Taht wrote:
> Suspectin
I retried it with edns0 set to 1500 bytes, and it worked (falling back
to tcp). 1800 bytes did not.
an osx box was the client.
I did capture the transaction(s) this time, the failing queries and a
working one are at: http://snapon.lab.bufferbloat.net/~d/dnsmasq/
One of my concerns has always bee
Suspecting edns0 (I am also using ipv6 only as my upstream forwarder),
i dropped edns_packet_max
dair-833:babeld d$ dig +dnssec www.ietf.org
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.8.3-P1 <<>> +dnssec www.ietf.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY
nslookup www.ietf.org fails again... it did not fail a few days ago.
chrome returns nxdomain
--
Dave Täht
Open Networking needs **Open Source Hardware**
https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
___
Dnsmasq-discuss mailing list
Dns
23 matches
Mail list logo
