Thanks to all for your help. I figured out what the problem was
(apparently, the RFCs not withstanding), several major DNS servers,
including bind, treat 'meta' RRTYPEs (128-255) as special, namely,
they will NOT process them or pass them, instead giving various
errors.
The test now uses a non-me
On Mon, Jan 10, 2011 at 10:53 AM, Jan Seiffert
wrote:
> This target is used to overcome criminally braindead ISPs or
> servers which block "ICMP Fragmentation Needed" or "ICMPv6
> Packet Too Big" packets. The symptoms of this problem are
> that everything works fine from your L
>
> Oh nevermind, it affect the TCP option negotiation, so it causes the client
> to send smaller packets. So it is a general solution for TCP (and only
> TCP). For UDP, the mtu still needs to be reduced at the client.
All but linux however do the right thing on UDP and don't send it with
DF sen
(Note: I don't have the version # with me right now, as the NAT in
question is at home, I can send taht tonight)...
Experimenting with DNSSEC (the Comcast no-wildcarding servers are now
full DNSSEC), I observed the following:
www.dnssec-failed.org is a (comcast owned) domain with deliberately
br
An A query for an only name should return a 0 answer NOERROR (so
"there is an answer, but no value")
nweaver% dig ipv6.l.google.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> ipv6.l.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59724
;; flags: qr r
On Jul 8, 2011, at 3:28 AM, Simon Kelley wrote:
> I don't know if this
>
> http://tools.ietf.org/id/draft-vandergaast-edns-client-ip-01.txt
>
> is going anywhere (the latest draft has expired) but if it does then
> support in dnsmasq may be in order.
I'd not bother supporting it in dnsmasq, it
On Dec 13, 2011, at 1:52 PM, Jason wrote:
> On Tue, Dec 13, 2011 at 09:53:09AM +, Simon Kelley wrote:
>> On 08/12/11 15:48, Jason wrote:
>>> I found this [1] comment from 2010 regarding source control. Have you
>>> considered migrating to one? I only ask because I'm partial to git (I
>>> us
On Mar 29, 2012, at 12:12 PM, richardvo...@gmail.com wrote:
>>
>> On thing which might be interesting, is to define a new type of upstream
>> server (maybe called a look-aside server) which dnsmasq will send a query to
>> first, and which if it can't answer the query can return a custom
>> re
On May 8, 2012, at 8:15 AM, starli...@binnacle.cx wrote:
> Hello,
>
> A problem of some sort exists with the list
> server configuration. All messages submitted
> from here bounce when relayed by a mature
> 'sendmail' configuration. Only way to submit
> messages is manually using 'nc' directly
>> gypsy wrote:
>>
>>> If Simon is offended, then so be it, but I mean no offense. I just fail
>>> to see how a save to/restore from disk could bloat the code;
>>> save/restore IS a basic feature. TTL will expire out any crap
>>> naturally.
>>> --
>>> gypsy
Speaking as just a general DNS guy (I'm
On May 15, 2012, at 10:46 AM, Timothy Madden wrote:
> Nicholas Weaver wrote:
>> Speaking as just a general DNS guy (I'm not a DNSMasq developer): Saving
>> cache state is stupid.
>>
>> TTL dictates a MAXIMUM that data can remain in the cache, but doesn't
On May 15, 2012, at 1:09 PM, Timothy Madden wrote:
> And you were right, using
> dig @8.8.8.8 ...
> returned about 54ms for www.loveparty.ch, and 38 for www.google.ro, which is
> so, so fast for me! But than again I would not like to just count on that
> (an external DNS provider), instead
I'm assuming this can be disabled for using DNSMasq in a corporate environment,
correct?
Assuming thats the case.
This looks good:
On Jun 12, 2012, at 8:26 AM, Simon Kelley wrote:
> 127.0.0.0/8(loopback) (separately configured)
> 192.168.0.0/16 (private)
> 10.0.0.0/8 (private)
> 17
On Jun 12, 2012, at 8:47 AM, Nicholas Weaver wrote:
> These clearly need the same treatment for records:
>
> FC00::/7 (Unique local unicast)
> FE80::/10 (Link local unicast)
Oh, and, of course ::1 (v6 loopback), duh.
There also may need to be something done with the IPv4-e
How does dnsmask respond to a DHCP request which doesn't come from the standard
source port?
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
On Nov 6, 2012, at 8:41 AM, Gene Czarcinski wrote:
> I look forward to it ... test7 is working well for me.
>
> Simon, I do not understand what "dig chaos txt version.bind" is suppose to
> mean/do.
>
> I tried it as you specified and also with one of my system's names in place
> of "chaos". I
f cases where this work is actually pretty
small, since a resolver which properly includes the DS record is going to
support the request for DNSSEC records.
Especially for the NAT case, the far better fallback is do an iterative fetch,
starting with the root and working down,
On Sep 30, 2014, at 1:05 AM, Roy Marples wrote:
>> Of course, the shell isn't supposed to interpret metacharacters in the
>> value of shell variables unless explicitly told to: so sanitising
>> shouldn't be required (though I concede it would mitigate a lot of
>> common shell-script errors.)
>
>
replies until it gets one which
validates DNSSEC completely, which can get rather messy rather quickly.
And its not like this actually stops the censor if it gets widely deployed: the
censor can instead recognize the TLS certificates for Facebook, Youtube, etc,
and packet inject a RST on those
On Oct 13, 2014, at 9:22 AM, Simon Kelley wrote:
>> (I am puzzled about the edns0 result, tho.)
>>
>
> Nicholas Weaver, of netalyzr fame, hangs out on here, so hopefully he'll
> be able to enlighten us.
>
I think its an android-specific reporting bug, since the
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
I'm one of the primary authors of Netalyzr (
http://netalyzr.icsi.berkeley.edu ).
One problem we test for that we see as absolutely endemic (>95% of the
cases tested) is NAT DNS proxies that can't handle unknown DNS
resource records.
RFC3597 specifically states how they should be handled (as opaq
n Kelley wrote:
> On 29/11/10 19:30, Nicholas Weaver wrote:
>
>> RFC3597 specifically states how they should be handled (as opaque
>> binary data which is passed unchanged), but almost all fail to process
>> our request for a made-up type (type # 169).
>>
>> a)
Oh wait, no it didn't pass...
We dump what we do to stdout and upload it at the transcript:
http://netalyzr.icsi.berkeley.edu/transcript/id=43ca208a-28815-3a04eee7-dbda-4220-84b4/side=client
The test in question is #31.
(I was looking at the wrong test, we also test the same name directly
to ou
Thanks all, this helps a lot!
A related question: The chaos txt version.bind query is very useful,
but is there a similar query to get the DNS server(s) that Dnsmasq is
forwarding to?
No worries, those queries will be useful enough. THanks!
On Tue, Nov 30, 2010 at 2:11 PM, Simon Kelley wrote:
> On 30/11/10 20:15, Nicholas Weaver wrote:
>>
>> Thanks all, this helps a lot!
>>
>> A related question: The chaos txt version.bind query is very useful
26 matches
Mail list logo
