On 15/06/2014 18:18, Mohamed Lrhazi wrote:
Also, been thinking that since we cant have both old and new IPs up at
the same time,
Unless this is a restriction imposed by your registrar, it is fine to
have multiple IP Addresses for one name server.
We ran tests on this and found multiple IP Ad
Recently, some servers seems to be only using bufsize=512 and so, for
signed zones, always falling back to TCP. This seemed to start about
11th Sep, but got significantly worse after the 6th Oct.
I seem to remember someone saying that the latest version of bind starts
with bufsize=512, but pre
I suspect you were slightly joking, but my guy feeling is that this
phenomenon is too common to be caused by an unusual configuration, but
must be a change in the default behaviour and the resolver s/w.
On 10/10/14 15:08, Roland Dobbins wrote:
On Oct 10, 2014, at 8:53 PM, Simon Munton
Which one(s) have been recently updated and are suspect? Would they really
have overwritten previously-configured options, or blithely added new ones
which were enabled by default?
Previously, bind has started with bufsize=4096 and reduced it if the
queried server says it can only provide sm
that bind will fall back to resend the query with EDNS size=512 if it does not
get an answer
We are replying to every UDP query, but the query is immediately
re-issued over TCP - if the reply was lost, I'd expect a delay.
The fact its immediately re-issued over TCP suggests (to me) this is i
My big concern is if this is an issue in a new release of bind,
Which new release of BIND?
I guess from whatever version starts from bufsize=512, instead of
bufsize=4096 - I don't follow bind source that closely.
I've attached (if this mailing list supports attachments?) an example of
two
On 11/10/14 10:56, Peter Koch wrote:
What makes you believe that your larger reponses (fragments?) really
make it through?
OK - I see what you mean now.
If someone, for example, was filtering UDP fragments somewhere in the
path, the effect would be the same.
A Path-MTU of 512 for so many r
BIND 9.10 starts at 512. If it gets TC=1 it will retry with TCP.
This establishes whether the server supports EDNS or not.
Even if the EDNS data is included in the TC=1 reply?
Named will record the actual size of the UDP response it gets and
use that, provided it is > 512 as the minimum when
Switching to TCP is quicker
I think this is a very short term view.
From the packet trace I posted, you just have to look at the sheer
number of packets, that running the same query over TCP causes, to have
an idea of extra load this is going to put on TLD Name Servers if all
resolvers start
(Sorry, this is not strictly DNS, but I would guess that this is the
cause of this shell-shock vector).
When looking at the code for libc I was most disappointed to see that
"/bin/sh" is hard coded for both "popen()" and "system()"
Where as I had previously assumed that the environment variab
As "/bin/sh" is almost always a symlink to "/bin/bash",
No. It is not the case for FreeBSD, Debian, NetBSD, ArchLinux...
On the archive Debian 5.0 system we have it is, & RH 5.11
On Ubuntu its linked to dash.
___
dns-operations mailing list
dns-oper
+1
On 14/10/14 14:41, Paul Vixie wrote:
the bash team really violated the principle of least astonishment with
function inheritance.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-oper
If a poisoning attack does not require access to a resolver, surely the
same attack will not require access to the end host?
Comes down to the age old argument of one big machine (easier to secure
but provides a bigger target) to billions of little machines (almost
impossible to be all secure
Yes - very common - certainly on older equipment.
On 23/10/14 10:23, Tony Finch wrote:
defeat source port randomization
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jo
Mark, I didn't see any reply to this; do you have anything to add?
Do you think this flawed assumption could be the cause of the surge in
TCP queries we have been seeing?
Most referrals even when signed will still fit in 512 bytes.
For most TLDs, for most referrals, this is *not* the cas
If you're feeling brave a WebUI to a conformance test would be nice
ditto "Handling of unknown EDNS versions"
On 24/11/14 23:19, Mark Andrews wrote:
We are looking to deploy DNS Cookies or SIT soon and the handling
of unknown EDNS options is atrocious.
http://users.isc.org/~marka/ts
What year is this? 1986?
Its a shame, cos over-reporting renders an alerts system useless.
The boy who cried wolf.
On 14/04/15 09:23, Stephane Bortzmeyer wrote:
https://www.us-cert.gov/ncas/alerts/TA15-103A
http://haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/
_
+1
On 14/04/15 15:17, Jan wrote:
I'm not sure this discovery should be dated 2015
___
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-oar
now that i've been reminded that the SOA timers are shorter than the
update frequency and that no NOTIFY is required for up-to-date stealth
slave service; and now that the root is signed, making it unlikely that
stealth copies will be amended or that their namespaces will be
overloaded with other
:
On 5/16/2012 10:04 AM, Simon Munton wrote:
I agree - I also think a formal documented infrastructure of first&
second level ROOT slaves could be useful to spread the load - similar
to NTP?
i hope we won't go that far. there's good reason why HOSTS.TXT is dead.
but doing this for
http://dnsviz.net/d/fbo.gov/T7YMCQ/responses/
Thanks Casey, your tool is extraordinarily helpful when explaining how
DNSSEC works!
Keep it up please!!
Sorry its off topic, but I second that - great tool - very useful.
i.e. using comcast's resolvers will be the same as using any other
validat
That sounds odd to me as CNAME records are not normally ever
specifically queried (asked) for.
Where they exist, they are given as reply to a query for any RR type,
but the CNAME itself is then followed by the resolver until an answer is
achieved.
e.g.
authority => www IN CNAME web1
query
If you are going to support NOTIFY then you will also need to catch the
NOTIFY/ACK - but otherwise ignore responses.
Presumably EDNS0 is handled in the library?
Some DNS server will probe with an IXFR to see if it is supported (over
TCP or UDP), but this behaviour can usually be switched off
Am I right in thinking that Google public DNS simply does not cycle
the multiple records on a round-robin host. There have been a few
threads on this (i.e. google "round robin 8.8.8.8")
If this is true, is it a stretch to see this impacting traffic
patterns on a host whose traffic is almost 100
You can also do it with the standard module "u32", including EDNS0, its
just more fun :)
On 03/08/2012 01:34, Ondřej Surý wrote:
Hi,
just a notice for those who don't know xt_dns[1]; it's a linux
kernel module which can be used to filter DNS queries based on
the type. There's one drawback - i
As with all monitoring, you also run into the interesting issue of "what
am I monitoring?". If the connectivity at your distant test point is
less reliable than your own, you get "you're down", when in fact they
are down (or somewhere in between). The result depends on the weakest link.
We tri
http://www.youtube.com/watch?v=SW_0s3kYT24
Counter statement - take your pick
If they have an anycast DNS network with nodes all over the world, each
peering into different IX's through different routers, its hard to see
how a single router issue could take all nodes out - but not impossible
We've been seeing 1000's of ANY queries/sec for many months, but use RRL
to filter them, so haven't been too bothered - mostly hitting our Tokyo
node.
http://stats.cdns.net/public/0.0.0.1/D4AE52-BBA337.html
But I can confirm we ARE getting the same pattern in the port & ID
I'm thinking a rate
Looks like I was wrong, you can't say "location = location" only
"location = constant / range"
On 12/09/2012 10:06, Simon Munton wrote:
I'm thinking a rate limiter in iptables using -u32 should be possible.
___
d
It probably depends on how your O/S handles the resolution - typically
Windows systems will try and resolve a dot-less name using a local LAN
broadcast looking typically for a PC on the same LAN segment by that
name - but it will depend on your config (e.g. domain controller or not,
LAN Manager
From 2am (UTC) this morning we've been getting a reflection attack
hitting mostly our node in LU, and a little on the one in RIPE.
Its very easy to spot, its an ANY query for "." (ROOT), and has EDNS0
packet size declared is 9000
Currently its below background noise, but be interested to know
very good - many laughs
On 09/04/2013 08:38, Stephane Bortzmeyer wrote:
On Wed, Apr 03, 2013 at 10:11:16AM -0400,
Joe Abley wrote
a message of 23 lines which said:
As advised a month or so ago, the following public comment period is open:
http://www.icann.org/en/news/public-comment/
On 16/04/2013 13:37, Phil Regnauld wrote:
skbroadband is interesting.
Is that Sky B/B?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://l
We were curious about this.
As a quick test we set up a zone with two name servers with two ipv4 addresses
each.
All four addresses received roughly the same query load and we saw no
resolution issues, but made no real attempt to search them out, this was just
based on polling various (open) r
34 matches
Mail list logo
