> On 24 Jul 2024, at 00:57, Warren Kumari wrote:
>
> Erm, probably nothing — this was sent to dns-operations (oarc), not dnsop
> (ietf).
> I’m not sure if you perhaps missed that — I know it often trips me up….
It did Warren. You’re not the first to mention that and I hope you’ll be the
las
> On 21 Jul 2024, at 18:24, John W. O'Brien via dns-operations
> wrote:
>
> I confirmed this with a domain under US and another one under COM. At least
> one other registrar, Porkbun, handles DNSSEC correctly when transferring a
> domain in. Namecheap support says that I am expected to set u
> On 27 Mar 2024, at 19:37, Ondřej Surý wrote:
>
> Both salt and iterations have absolutely no value for NSEC3 security (see the
> RFC you just quoted), so just always use empty salt and zero iterations.
> There’s no added value in fiddling with salt to fit into the SHA1 block.
IMO, there’s
> On 8 Jul 2022, at 21:46, John Levine wrote:
>
> The incumbent is Verisign. Any reason to believe they are looking
> to replace them?
It might just be the USG has to go through a procurement process for this sort
of thing every few years.
___
> On 14 Apr 2021, at 01:30, Paul Vixie wrote:
>
> that matches my recollection. there are other story elements, such as
> the working group meeting that devolved to queues of people shouting
> at each other from various microphones.
Paul, are you suggesting that’s only ever happened at *one* I
> On 1 Mar 2021, at 23:24, Doug Barton wrote:
>
> Back in the day, new name servers were created, and the host names of those
> name servers lived in one of the zones that were delegated to them. Glue
> records to the rescue! Now that entire zone, which includes those old name
> server host
> On 16 Dec 2020, at 19:33, Eugene Tsuno - NOAA Affiliate via dns-operations
> wrote:
>
> So do those who have subdomains delegated have to regenerate DS keys ever?
Yes. This *has* to be done whenever the child zone rolls its KSK. And every
zone should change its KSK from time to time, just
> On 9 Nov 2020, at 04:15, Hoan Vu wrote:
>
> We really wanna know "what is round robin of DNS" and the nature of the rule
> to choose the DNS Root of Resolver, what factor, algorithm, that decide
> the choice of DNS Root.
Why? Nobody needs to care about this - apart from the people who
> On 16 Sep 2020, at 14:57, Peter van Dijk wrote:
>
> Your comments in the thread are loud, rude, and almost consistently incorrect.
A near-perfect summation in 12 words of every discussion about systemd. :-)
___
dns-operations mailing list
dns-op
> On 25 Aug 2020, at 03:30, Fred Morris wrote:
>
> I think the question has to be: why would someone be joining this chat
> channel and who would they be?
No. The question should be why are we having this silly discussion?
There’s no justification for this outburst of shed-painting.
Quite s
> On 2 Apr 2020, at 11:10, Davey Song wrote:
>
> I'm very confused that why people on the list are suggesting RRL (even BCP38)
> to the victim of DoS attack? If I remember correctly, the goal of both RRL
> and BCP38 is to reduce the chance of participating the attack as a innocent
> helper.
> On 6 Feb 2020, at 09:08, Pirawat WATANAPONGSE wrote:
>
> So I am now wondering whether we were contacting the wrong team, and
> register.com is no longer responsible for DNSsec operations of .org
register.com have never been responsible for the DNSSEC operations of .org.
These lie with PIR
> On 11 Dec 2019, at 12:51, Stephane Bortzmeyer wrote:
>
> IMHO, this is by far the biggest issue with your proposal: TLDs change
> from one technical operator to another and, when it happens, all name
> servers change at once.
That’s not correct.
In principle, they could all change at once,
> On 3 Dec 2019, at 20:38, Nico Cartron wrote:
>
>>
>> if anyone has contacts to national-lottery.co.uk/camelotinteractive.com
>> please ask them to rethink the 30s ttl on NS and MX records.
>>
>> Thanks for your help.
>
> Maybe worth posting on UKNOF as well?
Contacting the registrars for
> On 26 Nov 2019, at 09:16, Florian Weimer wrote:
>
> Up until recently, well-behaved recursive resolvers had to forward
> queries to the root if they were not already covered by a delegation.
> RFC 7816 and in particular RFC 8198 changed that, but before that, it
> was just how the protocol w
> On 25 Nov 2019, at 22:31, Paul Ebersman
> wrote:
>
> Actually, it's a great argument for longer TTLs and caching doing what
> they're supposed to.
It would be if the root only got queries from well behaved recursive resolvers.
But we both know Paul that simply isn't true.
Well over 90% o
> On 25 Nov 2019, at 22:19, Florian Weimer wrote:
>
>> What do you consider to be a lot of queries? The root server system
>> collectively handles 500K-1M queries per second. That seems rather a
>> lot to me. YMMV.
>
> But globally? For the entire planet?
Yes. If you consider a well-behaved
> On 25 Nov 2019, at 20:54, Florian Weimer wrote:
>
> The query numbers are surprisingly low. To me at last.
What do you consider to be a lot of queries? The root server system
collectively handles 500K-1M queries per second. That seems rather a lot to me.
YMMV. I don't know of any other I
> On 13 Nov 2019, at 06:25, Wesley Peng wrote:
>
> Is .gmx tld run by United Internet?
Knipp Medien und Kommunikation GmbH operate the DNS servers for this gTLD.
% whois irondns.net
...
Registrar WHOIS Server: whois.corehub.net
Registrar URL: http://corehub.net
...
Registrar Abuse Contact
> On 23 Oct 2019, at 11:34, Greg Choules wrote:
>
> Hi Jim. You get the first response prize :)
Where and when do I collect my fabulous cash prize? :-)
> It appears that Amazon are blocking queries of type CNAME. I'm guessing
> because they have identified these are the basis of the attack.
> On 23 Oct 2019, at 09:25, Greg Choules via dns-operations
> wrote:
>
> Is anyone else experiencing resolution issues for names in this domain? We
> are seeing a lot of queries of the form:
> CNAME? bvusfvyq.s3.amazonaws.com
> (the label before ".s3" looks random) and a lot of SERVFAIL respo
On 8 Jun 2015, at 11:05, Stephane Bortzmeyer wrote:
> % dig @dwdns1.nsbeta.info defensor.game.yy.com | grep NOERROR
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51459
>
> % dig @dwdns2.nsbeta.info defensor.game.yy.com | grep NOERROR
> ;; ->>HEADER<<- opcode: QUERY, status: N
On 8 Jun 2015, at 10:01, Kevin C. wrote:
> On 2015/6/8 星期一 16:49, Jim Reid wrote:
>> FWIW there's an inconsistency between the two authoritative name servers for
>> game.yy.com. dwdns1.nsbeta.info returns NOHOST while dwdns2.nsbeta.info
>> retur
On 8 Jun 2015, at 10:28, Stephane Bortzmeyer wrote:
>>
>> FWIW there's an inconsistency between the two authoritative name
>> servers for game.yy.com. dwdns1.nsbeta.info returns NOHOST while
>> dwdns2.nsbeta.info returns NXDOMAIN for lookups of
>> defensor.game.yy.com QTYPEs.
>
> This is not w
On 8 Jun 2015, at 10:20, Stephane Bortzmeyer wrote:
> On Mon, Jun 08, 2015 at 09:49:34AM +0100,
> Jim Reid wrote
> a message of 21 lines which said:
>
>> A NOERROR response with an empty Answer Section -- usually known as
>> a NOHOST response
>
> Never seen
On 8 Jun 2015, at 09:12, Kevin C. wrote:
> Sometime I got "NOERROR" from the answer, but sometime got "NXDOMAIN".
> At what case the nameserver returns "NOERROR" or "NXDOMAIN" for a non-exist
> record? Thank you.
A NOERROR response means just that: there was no error. A NOERROR response with
a
On 27 Mar 2015, at 20:56, Warren Kumari wrote:
> I was saying is that we don't really need to reach *every* recursive,
> whatever we do manage to do will be better than the current position.
I disagree Warren. What's wrong with the status quo? Why can't it be left to
the discretion of each mana
On 9 Dec 2014, at 17:12, Randy Bush wrote:
> this is an amusing list. i can understand EXAMPLE, LOCALHOST, and TEST.
> maybe even WHOIS and WWW. but the rest sure look as if lawyers wanted
> and got what is in effect a super trademark.
Who cares? The names were ring-fenced some years ago and n
On 14 Oct 2014, at 12:46, P Vixie wrote:
>> As "/bin/sh" is almost always a symlink to "/bin/bash", and many O/S
>> scripts assume this to be the case (i.e. use bash specific features,
>> without declaring "#!/bin/bash"), so simply making "/bin/sh" a link to
>> (say) "/bin/ash" is probably not
On 2 Jul 2014, at 11:29, Mohamed Lrhazi wrote:
> I am sure I messed up something, but cant figure out what! Some DNS
> servers, notably Google's, return SERVFAIL, since a couple of days now.
DNSSEC for gu.edu appears to be broken. google's 8.8.8.8 service does DNSSEC
validation. SERVFAILs get r
On 24 Jun 2014, at 17:29, Robert Willmann wrote:
> In my opinion it's a pity that there is no reserved domainname for the
> private use.
A few attempts have been made to (sort of) do this. See RFCs 2606, 6761 and
6762.
draft-chapin-additional-reserved-tlds-00 is working its way through the
On 23 Jun 2014, at 21:28, Kelly Setzer wrote:
> What is current thinking/accepted practice for internal domain names?
>
> RFC 2606 seems to suggest using a registered domain. That¹s great except
> that split-brain inevitably creeps into the equation. Is this a case of
> choosing the ³least wor
On 29 May 2014, at 18:56, wbr...@e1b.org wrote:
> Out of curiosity, where did the prohibition of underscores in host names
> come from. I'm sure there's a historical reason for it, but I've never
> heard it. Or is it really as simple as "RFC 952 only listed thirty seven
> characters"
I belie
On 29 May 2014, at 18:20, Bob Harold wrote:
> If I (reluctantly) accept that DNS names that are not hostnames can have
> underscores in them, why does BIND not have an option to allow that, while
> still rejecting invalid hostnames? Or have I missed something?
I think you have missed something.
On 13 May 2014, at 22:51, Andrew Sullivan wrote:
> "Check every name using your nameservers at the parent side for glue before
> renumbering".
If only it was that simple Andrew. :-)
A delegation in TLD1 might point at a name in TLD2. So when the reference count
for ns.foo.tld2 drops to zero,
On 3 Mar 2014, at 17:26, Stephen Malone wrote:
> 1. In general, can I trust PTR records? Is ownership of the target
> domain validated at setup time by ISPs, and if yes, how is this done?
Define what you mean by "trust" and "validate". For bonus points, define
"ownership".
> 2. If
On 28 Jan 2014, at 15:43, Daniel Sterling wrote:
> Would it be possible for the larger DNS community to blacklist and
> stop serving domains from registrars that are known to be friendly to
> malware authors?
In theory it would be possible. So is herding cats.
DNS is not the appropriate tool to
On 12 Jan 2014, at 15:34, Chris Thompson wrote:
> But what about the simply informative/debugging:
>
> kiwi. 86400 IN TXT "Generation Time: 1389539700"
Sigh.
Seems a waste of time to me. What is the "generation time", what does it mean
and what does that digit string represent? [OK, it's
On 27 Nov 2013, at 08:10, SM wrote:
> Some root servers allow AXFR; some do not allow AXFR.
So what? The root zone file is freely available to anyone who wants it. AXFR
from a root server is not the only mechanism to get a copy. And as Joe just
said, it's not necessarily a Good Thing for resol
On 26 Nov 2013, at 20:22, Vernon Schryver wrote:
> If those diagnoses are correct that the probes are for subdomains of
> the local hosts's domain
I'll be charitable. If these diagnoses are correct they fail to tell the full
story.
It's not possible to predict what the code does unless someone
On 26 Nov 2013, at 19:23, Vernon Schryver wrote:
> If the probing test requests are for domains that Google owns or has
> permission for junk queries, then no one outside Google has standing
> to complain.
+1. However the lookups I was talking about are not going to name servers that
google own
On 26 Nov 2013, at 17:29, Damian Menscher wrote:
>> Which follows the known Chromium (main Google Chrome component) pattern of
>> a few random 10-character requests for every search query to make such
>> detection.
>
> I didn't realize Chrome did that -- nice trick!
This is definitely not a n
On 15 Nov 2013, at 16:17, Paul Wouters wrote:
> I'm also very worried that ICANN has still not added "mail" to the list
> of TLDs they will never delegate. There are _many_ mailservers that are
> called "mail" internally with many different types of custom written
> applications and mail clients
On 7 Nov 2013, at 20:08, Joe Abley wrote:
> But if that's what happens, it certainly helps explain the oft-shouted
> guidance "TUNE YOUR CACHE".
Maybe. However it wouldn't explain why the oft-shouted phrase wasn't "spend $50
on a a few more GB of memory". :-)
PS: apologies for a meaningful Su
On 29 Oct 2013, at 09:24, Calvin Browne wrote:
> I'm going to point out that .se went down because of a problem right at this
> point relativly recently.
IIRC, that problem had nothing to do with whether the TLD's NS RRset was in the
zone or not. Something went wrong with zone file generation
On 22 Oct 2013, at 22:53, Rubens Kuhl wrote:
> .nl and .cz got massive registrar adoption to DNSSEC offering business
> incentives, so it seems business side accounts for most of it.
So where are the incentives for resolver operators? If they switch on DNSSEC
validation and get extra calls to
On 21 Oct 2013, at 16:54, Keith Mitchell wrote:
> Applying the same 5-years' now-outside hindsight to this, the benefits
> of all that port randomization work seem murky at best -
There was/is a vulnerability and it's been (sort of) plugged. Surely that's a
Good Thing? Even if it just means the
On 20 Oct 2013, at 17:14, Anne-Marie Eklund-Löwinder
wrote:
> https://twitter.com/Official_SEA16/status/391339315562688513
If it's on Twitter it must be true, right? :-)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists
On 13 Oct 2013, at 08:26, Marco Davids (SIDN) wrote:
> Interesting thought, but I don't know, Jim. Sounds like some way of
> circular dependency to me?
Maybe Marco. I did say I was hand-waving though. :-)
That said, there might be some merit in a scheme like the one I outlined.
Assuming of cou
On 10 Oct 2013, at 16:43, Dan York wrote:
> there's nothing that DNSSEC or anything else could have done here
Perhaps that's the case for the incidents you described Dan.
However DNSSEC could help provide some form of two-stage authentication for
these sorts of requests. Says he hand-waving...
On 11 Sep 2013, at 06:30, Paul Vixie wrote:
> excuse me, i left an edit out of my earlier proposal.
>
> This specification does not define a maximum for any future IP transport
> protocol, and so both initiators and responders should be prepared to
> receive messages as large as the 9 kilobyte e
On 4 Sep 2013, at 15:40, Ondřej Surý wrote:
>> Check also ICMP "packet too big" coming in with ridiculous sizes, they
>> might be the sign that someone is trying the Shulman attack.
>
> True, but again, that might work for us, but not for average DNS operator.
Indeed. But who is more likely to
On 4 Sep 2013, at 15:34, Stephane Bortzmeyer wrote:
>> Don't fragment at all, set TC=1 on responses which would cause UDP
>> or lower layer fragmantation
>
> Not obvious to implement, the application (the name server) typically
> does not know the path MTU before sending an UDP packet to a
> de
On 4 Sep 2013, at 15:04, Ondřej Surý wrote:
>> A possible solution is simply to deploy IPv6 faster :-)
> Yeah :), but what should we do in the eternity meanwhile?
Don't fragment at all, set TC=1 on responses which would cause UDP or lower
layer fragmantation and assume only genuine queries wi
On 9 Aug 2013, at 09:14, Ken Peng wrote:
> My nameservers are auth-only. that means we are the auth-servers for that
> domain.
=> you have to answer those queries. If you think you're getting flooded,
consider blacklisting the source IP addresses or using traffic shaping or
applying DNS rate-
On 23 May 2013, at 14:39, Vitalie Cherpec wrote:
> I would like to know if querying version.bind is illegal (in
> some countries)?
Ask a lawyer or policeman in those countries. It's hard to see how such largely
useless queries could be illegal or result in a successful prosecution. Or get
you
On 1 Apr 2013, at 21:17, Robert Edmonds wrote:
> so that just leaves the decision of who gets to operate the new N-root
> DNS server.
Best not explode that can of worms. Ever.
I suggest we all quietly tiptoe away from any discussions about how to squeeze
more payload into the priming query and
On 31 Mar 2013, at 17:09, Vernon Schryver wrote:
> What's the profit for the bad guy in spending 10 bps of botnet
> bandwidth to reflect 9 bps at the target?
Having the reflected traffic appear to come from trusted name servers instead
of his botnet perhaps? Though since the botnet almost certa
On 31 Mar 2013, at 15:20, Stephane Bortzmeyer wrote:
> On Sun, Mar 31, 2013 at 01:32:13PM +0100,
> Jim Reid wrote
> a message of 23 lines which said:
>
>> Keeping state for bazillions of DNS TCP connections to a resolving
>> server will present further challenges.
On 31 Mar 2013, at 15:30, Vernon Schryver wrote:
>> From: Jim Reid
>
>> I'm not sure it will make a difference though. The bad guys won't
>> bother to do TCP for the obvious reason and will stick with their
>> current, DNS protocol conformant, behaviour.
&
On 31 Mar 2013, at 14:36, "Patrick W. Gilmore" wrote:
> CloudFlare, CacheFly, and a few other CDNs who anycast web server addresses
> would probably disagree.
Yeah. We both know we have had those discussions before Patrick and (hopefully)
agreed to disgagree. :-)
>> Keeping state for bazillio
On 31 Mar 2013, at 10:30, Xun Fan wrote:
> So do you think "force TCP for external queries to OR" is a feasible
> solution to DNS reflect amplification problem?
It's a nice idea that's worth trying.
I'm not sure it will make a difference though. The bad guys won't bother to do
TCP for the obvi
On 22 Feb 2013, at 17:55, Jo Rhett wrote:
> Don't confuse "won't" with "can't". It absolutely can be done.
With sufficient thrust, even pigs can fly.
There's no point arguing the semantics of "don't" and "can't". As Paul
mentioned earlier, let's remain realistic. Universal deployment of BCP38
On 21 Jan 2013, at 11:54, Stephane Bortzmeyer wrote:
> And 95 % of these uses are bad ideas: it creates false positives
> (.CW...) and false negatives (it's not because .COM exists that
> anything.com has a meaning).
Indeed. FWIW I stopped despairing years ago about the bad and/or downright
stu
On 21 Jan 2013, at 13:56, "Carlos M. Martinez" wrote:
> I certainly hope that lousy web programmers start feeling the hot breath
> of pissed off people who have just spent a gazillion dollars on their
> new TLD just to have their shiny new ".whatever" emails be considered
> 'invalid' by some idio
On 13 Jan 2013, at 16:28, Vernon Schryver wrote:
>> If the problem is amplification, why not only perform RRL on only those DNS
>> communications exchanges that have certain amplification factor (i.e. 1.5).
>>
> That sounds nice but has problems. The main one for me is that
> you'd have wait
On 10 Jan 2013, at 17:39, Matthew Ghali wrote:
> So if I understand correctly, the solution you are advocating is to only
> answer non-spoofed queries?
It's one of them, yes. Though since it's hard for a DNS server to distinguish
between spoofed and genuine source IP addresses, the RRL patch i
On 10 Jan 2013, at 15:00, Paul Wouters wrote:
> On Thu, 10 Jan 2013, Jim Reid wrote:
>
>> IMO, responding to these spoofed queries is a Bad Idea.
>
> Not responding is worse.
>
> - valid recursors will just retry
>
> - valid recursors might conclude the auth
On 10 Jan 2013, at 09:53, George Michaelson wrote:
> What makes you think they won't? I mean, isn't this a classic mistake of
> cold war defense modelling, that you assume your enemy will use weapons you
> can confidently defend against and ignore the ones you suspect you cannot?
It would be if
On 10 Jan 2013, at 07:11, Florian Weimer wrote:
> Some breakage is unavoidable. Considering that ANY queries rarely
> give the results expected by the sender, refusing them outright makes
> sense to me.
+1
IMO, responding to these spoofed queries is a Bad Idea. After all, the object
of the at
On 16 Oct 2012, at 03:48, Bill Woodcock wrote:
The big problem comes if you select different transit providers in
different locations. That's what Patrick is alluding to when he
says that London queries can be directed to Tokyo servers… Network
operators will always deliver to a customer
On 13 Oct 2012, at 09:31, pangj wrote:
My question is, if we want to deploy a global DNS service, how to get
the anycast networks?
We are a small company in Asia, don't have our own ASN.
So the only way is to rent a anycast network from an ISP or IDC?
Yes. Or buy anycast DNS service from one o
On 11 Oct 2012, at 10:31, Simon Munton wrote:
we've been getting a reflection attack ... on the one in RIPE.
Please explain. RIPE is a network meeting/community with no legal
identity. It has no assets and doesn't operate any network
infrastructure. Is RIPE NCC hosting something for you?
On 3 Oct 2012, at 02:42, Vernon Schryver wrote:
Why not get rid of stub resolvers completely and simply use
recursive resolvers?
I think the code to parse the BIND9 configuration grammar and nothing
more would be excessive and grotesque.The code to support all of
that stuff would be obsce
On 1 Oct 2012, at 08:33, Paul Vixie wrote:
i'm ready to accept that rate limiting (as specified by DNS RRL) hurts
non-spoofing clients who ask "similar enough" questions during the
attack. but so far this has not been demonstrated or even described. a
real recursive-service initiator may be forc
On 23 Sep 2012, at 09:38, Fred Morris wrote:
I don't understand this entire debate. I am sorry. Can somebody please
frame it?
Read the SSAC report: http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf
.
So what, exactly, *is* the security implication?
There are many. You even men
This thread is becoming tiresome. Could those who want to continue
what ICANN should and shouldn't do about making rules for dotless
domains, please take the discussion elsewhere? Thanks. ICANN is in the
middle of a public comment period on dotless domains (http://www.icann.org/en/news/public
On 21 Sep 2012, at 10:07, Bart Smit wrote:
Phil Regnauld wrote:
Surprised no one's brought up http://dk/ as an already existing
scenario
that doesn't work (try it in various browsers).
Bad example. The first *four* browsers I tried (firefox, chrome,
safari,
and opera on osx) handle this
On 21 Sep 2012, at 09:40, Stephane Bortzmeyer wrote:
For the consultation mentioned in Paul Vixie's original message, the
issue is not whether one-label domains are a good idea or not but
whether ICANN has really nothing better to do than to add yet another
stupid regulation in an already very t
On 8 Aug 2012, at 21:54, David Conrad wrote:
Paul Mockapetris founded Nominum? How offensive!
Indeed. Everyone knows it was founded by Dan Bernstein. :-)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/ma
On 23 Jul 2012, at 10:02, Jan-Piet Mens wrote:
It is more complicated, specially with DNSSEC validation. Did anyone
try running that on his Android?
SIDN Labs experimented with LDNS on iOS and got libUnbound working
with validation. [1]
There's a world of difference between getting something
On 20 Jul 2012, at 08:27, 风河 wrote:
Rather than godaddy is there any other registrar support that?
I expect so. However I can't be bothered to do your homework for you.
Sorry.
Perhaps the registrars on this list who can meet your needs will
contact you.
__
On 20 Jul 2012, at 07:59, 风河 wrote:
But with other registrars like Networksolutions and Namecheap, I can
setup a nameserver with only one IP.
I have a NS domain in Networksolutions, how to resolve this problem
rather than transfer it into godaddy?
You can't. Move to another registrar who do
On 9 Jul 2012, at 16:39, Edward Lewis wrote:
Should DiG's output be unchanged or is this "good?" Should the OS
vendors be asked to stop this?
IMO, dig should only display what's actually in the DNS packets. Some
other tool(s) can be used to render IDNs into whatever non-ASCII
scripts/fon
On 18 Jun 2012, at 12:36, Kostas Zorbadelos wrote:
Stephane Bortzmeyer writes:
If you don't do ingress filtering, it still allows people to attack
your users (they can send from the outside a "ANY ripe.net" query
claiming to be from a local machine).
The same is true if you have open resolv
On 10 Jun 2012, at 22:59, Kyle Creyts wrote:
Someone mentioned that as soon as the spoofed client is blocked, that
a new spoofed client is used... This behavior seems... strange.
I did and I was wrong.
My logs tended to have a few hundred entries at a time for the same
(spoofed?) IP address
On 10 Jun 2012, at 17:20, Jan Inge Sande wrote:
I'm seeing the same attack as Jim Reid described on one of my
nameservers too (just found the "source"/target address on Gmane and
signed up for the mailinglist), at ~3Kqps/1.3Mbits at the moment (in
Germany, AS24940). No UD
On 10 Jun 2012, at 12:57, Stephane Bortzmeyer wrote:
What about forcing TCP for ANY requests only?
It would be worth measuring and testing IMO. I doubt it would be a
change for the better. Forcing kernels to maintain zillions of PCBs
for short-lived TCP connections would be very bad. Thoug
On 10 Jun 2012, at 09:19, DTNX Postmaster wrote:
What type of queries?
ANY queries for ihren.org with no UDP checksum:
shaun# tcpdump -vv -n port 53
09:32:30.139803 IP (tos 0x0, ttl 251, id 24876, offset 0, flags
[none], proto UDP (17), length 66) 37.221.160.125.28832 >
93.186.33.42.53: [
My name server has been getting hammered with queries for ihren.org --
one of the zones it serves -- since around 00:00 GMT today. [The
attack may have started earlier and I just didn't notice it.] The box
is getting ~400 qps for this name. The queries come from the same IP
address, just re
On 16 May 2012, at 18:07, Joseph S D Yao wrote:
On Wed, May 16, 2012 at 09:31:29AM +0100, Jim Reid wrote:
...
easily serve a zone containing a few million names. [And FWIW I very
much doubt the vanity TLD madness will continue long enough for the
root zone grow to anywhere like that size
On 16 May 2012, at 08:53, Mark Andrews wrote:
The only problem with this is ICANN wanting to make the DNS a flat
namespace by adding lots of vanity TLDs. As these grow the space
required to serve "." increases and it will only be possible to do
this with large servers.
Nonsense. A $300 box f
On 15 May 2012, at 08:23, Stephane Bortzmeyer wrote:
http://royal.pingdom.com/2012/05/07/the-very-uneven-distribution-of-dns-root-servers-on-the-internet/
Technically very interesting (many numbers) but the author does not
seem to know how the root name servers are managed.
Sigh. The author o
93 matches
Mail list logo
