On 11 Sep 2014, at 3:54, Keith Mitchell ke...@dns-oarc.net wrote:
I can confirm that we still have *plenty* of capacity in our room block
until CoB today, and having also just tried it the link certainly stil
works for me. Is it possible you asked for dates outside our 10th-17th
October
Hello,
We run a public resolver and a few days ago I noticed a lot of very
weird queries, like the following:
16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A?
swfjwvtkhqx.www.feile.com. (47)
16:11:41.450796 IP 91.209.124.75.50584 62.76.76.62.53: 37269+ [1au]
A?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello All,
I am having difficulty resolving Reverse DNS for 167.216.129.170,
and I'm not entirely certain why. If I just do a dig -x
167.216.129.170 I get:
; DiG 9.7.3 -x 167.216.129.170
;; global options: +cmd
;; connection timed out; no
On Sep 11, 2014, at 8:42 PM, Peter Andreev andreev.pe...@gmail.com wrote:
I'd like to ask the respected community, how do you detect and protect
against such activity?
What we've seen of this particular attack methodology (as you rightly
deduced) over the last six months or so indicates that
On Sep 11, 2014, at 8:42 PM, Peter Andreev andreev.pe...@gmail.com wrote:
One of those SLDs is an online-shop, another is online-casino, so I concluded
that our
resolver is being used to bombard NSes of corresponding SLDs with queries.
Also, in some cases, we've seen this activity constitute
On Thu, Sep 11, 2014 at 04:38:25PM +0400, Peter Andreev wrote:
I'd like to ask the respected community, how do you detect and protect
against such activity? Will RRL help me if all suspected queries come
with random qname?
No, it will probably not, since the answers are all servfails.
On Thu, Sep 11, 2014 at 04:38:25PM +0400,
Peter Andreev andreev.pe...@gmail.com wrote
a message of 29 lines which said:
a lot of very weird queries, like the following:
16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A?
swfjwvtkhqx.www.feile.com. (47)
16:11:41.450796
Another data point for you:
On Aug 28, I wrote this open message on the NANOG mailing list:
I discovered that NetSuite's dns servers ens0 1 .netsuite.com are
invisible from Comcast's business services in the Chicago area(limits of
my testing abilities) but I can reach these same servers from
In message 54119aeb.8070...@brockmans.com, Dave Brockman writes:
Hello All,
I am having difficulty resolving Reverse DNS for 167.216.129.170,
and I'm not entirely certain why. If I just do a dig -x
167.216.129.170 I get:
; DiG 9.7.3 -x 167.216.129.170
;; global options: +cmd
;;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you, and thank you Mark for reminding me to start my coffee :)
Regards,
dtb
On 9/11/2014 9:13 AM, Lyle Giese wrote:
Another data point for you:
On Aug 28, I wrote this open message on the NANOG mailing list:
I discovered that
On Thu, Sep 11, 2014 at 09:00:37PM +0800,
Roland Dobbins rdobb...@arbor.net wrote
a message of 29 lines which said:
FYI, most of these queries seem to be reflected through abusable CPE
devices which are misconfigured by default as open recursors or DNS
forwarders. It may be worth
On Sep 11, 2014, at 9:46 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
Many open resolvers do not forward directly but send to a big resolver
such as Google Public DNS (which you cannot obviously blacklist). The
authoritative name servers therefore do not see directly the open
resolver.]
Many registries, if not most, don't let you delegate a zone to
arbitrary name-servers. Instead those nameservers need to be
registered in some way.
Typically anyone can register a name server, and it once it's done,
many zones can be delegated to that name server. A small number of
CC-TLDs also
That's exactly my case with the only difference - mathematics doesn't
work for me. However I like author's idea and going to try to find
similar coincedences.
2014-09-11 17:11 GMT+04:00 Stephane Bortzmeyer bortzme...@nic.fr:
On Thu, Sep 11, 2014 at 04:38:25PM +0400,
Peter Andreev
Colm
For gTLDs the nameservers have to be registered via a registrar
Some of the ccTLDs also demand payment and other oddness for adding them
I suspect a lot of this is legacy .. no idea though
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation Domains
On Thu, Sep 11, 2014 at 07:52:31AM -0700,
Colm MacCárthaigh c...@stdlib.net wrote
a message of 26 lines which said:
So why is it that name servers need to be registered? What's the
benefit of doing it?
As an employee of a registry which does not require name server
registration, I wonder,
On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh wrote:
Many registries, if not most, don't let you delegate a zone to
arbitrary name-servers. Instead those nameservers need to be
registered in some way.
I don't know about other kinds of registration systems, but in
EPP-based ones
Hi,
Guess the first people are now finding out that .prod went live. I heard
from a large webhoster that their sysadmins use db1.prod for a
shorthand of db1.prod.corp.com. They are now attempting to go to
the 127.0.53.53 warning pit.
I had never through of prod being a problem. but it might
I'd always thought that this was kinda because of the way EPP is written --
not that it is actually required, but when reading the docs you see the
nameservers object and kinda assume...
I think at this point much of it is hysterical raisons.
W
On Thursday, September 11, 2014, Stephane
I'm going to be open sourcing a php class I wrote awhile back that we
use internally for finding the delegated nameservers for a specified domain.
This is distinct from host -C or doing a type=ns query because while
those will look at what are *thought* to be the NS records for the
domain (as
On Thu, 11 Sep 2014 12:19:00 -0400
Mark E. Jeftovic mar...@easydns.com wrote:
Is there already any tool specifically outputs the authoritative
nameservers as they are delegated in the rootzone for a domain?
I did something close to this years ago. It looks like it even still
works. :-) I
Perhaps they need to set the ‘ndots’ option in
resolv.conf to trigger absolute queries if they find more than 1 dot,
so something like:
options ndots 2
would prevent a query to the .prod. TLD.
from ‘man resolv.conf’
ndots:n
sets a threshold for the number
Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?
One the one hand, requiring that nameservers be registered creates
downward pressure on the number of active authoritative name server
names in the world, which has benefits for cache
On Thu, Sep 11, 2014 at 09:34:32AM -0700, Colm MacCárthaigh wrote:
Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?
From the point of view of data management, I think it is an unalloyed
good. I always thought the nameserver-as-attribute
Vanity nameservers would not be very useful in DDoS mitigation (in terms
of isolating your target) unless you actually create unique IP address
nameserver records for each one.
That's all you'll see in the attack, which IP's the attack is coming
toward, not the hostnames of the vanity nameservers
On 11/09/2014 13:38, Peter Andreev wrote:
Hello,
We run a public resolver and a few days ago I noticed a lot of very
weird queries, like the following:
16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A?
swfjwvtkhqx.www.feile.com. (47)
16:11:41.450796 IP
On Thu, Sep 11, 2014 at 12:46:50PM -0400, Andrew Sullivan wrote:
On Thu, Sep 11, 2014 at 09:34:32AM -0700, Colm MacCárthaigh wrote:
Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?
From the point of view of data management, I think
Our current thinking (based on evidence from some of our customers, and
also from Nominum's analysis presented at the Warsaw DNS-OARC workship
earlier this year) that the majority of these recent query spates are
intended as an attack on the domain (e.g. feile.com) or the
nameserver
Although the attack could be done with a botnet or by reflecting traffic
off end-user equipment, many of the attacks I have seen involve source
IP spoofing. I deduce this by noting that a fairly large percentage of
the traffic comes from blocks of IPs that are not currently routed on
the open
On 9/11/2014 9:07 AM, Paul Wouters wrote:
Guess the first people are now finding out that .prod went live. I heard
from a large webhoster that their sysadmins use db1.prod for a
shorthand of db1.prod.corp.com. They are now attempting to go to
the 127.0.53.53 warning pit.
I had never
In message caaf6gdejb5nw40m4ew58vxwssmlzroeaxvb0vtptf_kfwd+...@mail.gmail.com
, =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writes:
On Thu, Sep 11, 2014 at 9:46 AM, Andrew Sullivan a...@anvilwalrusden.com wro
te:
Also, it's not like it's terrifically onerous, although I know some
registrars' web
Robert wrote:
Can't you win in either case? If they don't re-resolve you could just
move everyone else off of those IPs by updating the DNS entries for
the unique nameserver labels to those zones. If they do re-resolve you
just move that single unique name to a different IP.
I'm not
On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews ma...@isc.org wrote:
Which indicates broken recursive servers. Recursive servers should
be expecting misconfigured authoritative servers. You don't stuff
up authoritative behaviour because you have broken recursive servers.
I do whatever is best
Is there already any tool specifically outputs the authoritative
nameservers as they are delegated in the rootzone for a domain?
res_findzonecut(), inside libbind (now called netresolv), provides an
API that does what you don't want (gets the zone's apex NS RRset), but
is implemented with logic
From the point of view of data management, I think it is an unalloyed
good. I always thought the nameserver-as-attribute approach was
dramatically worse. Particularly for internal host objects, the
enforced consistency of the glue for every domain that's using it is a
giant help.
It was
On 9/11/2014 5:22 PM, Colm MacCárthaigh wrote:
On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews ma...@isc.org wrote:
Which indicates broken recursive servers. Recursive servers should
be expecting misconfigured authoritative servers. You don't stuff
up authoritative behaviour because you have
On Thu, Sep 11, 2014 at 09:35:40PM -0300, Rubens Kuhl wrote:
It was curious to see that a to-be-unnamed TLD registry, a newcomer
to the scene many years after the holy wars that ended up defining
the current RFCs, writing completely new code, mentioned that they
found attributes to be a
On 9/11/2014 6:30 PM, Paul Vixie wrote:
... i have a lot of data but no obvious way to distill this
determination out of it.
as to this part, let me quote what i said on another mailing list
earlier today, on a similar thread (.PROD collisions):
On 9/11/2014 2:57 PM, Paul Vixie wrote:
...
Probably something I should know. But what's the best way to get notified of
new TLDs coming online to help arm the NOC?
--
Josh Smith
KD8HRX
Email/jabber: juice...@gmail.com
Phone: 304.237.9369(c)
Sent from my iPhone.
On Sep 11, 2014, at 9:32 PM, Paul Vixie p...@redbarn.org wrote:
On
On Thu, Sep 11, 2014 at 09:58:59PM -0400, Joshua Smith wrote:
Probably something I should know. But what's the best way to get notified of
new TLDs coming online to help arm the NOC?
Probably the _best_ way is to get copies of the root zone. There's
also
In message 45b62715-b7f9-439e-81b3-6c7356e88...@vpnc.org, Paul Hoffman writes
:
On Sep 11, 2014, at 4:27 PM, Paul Vixie p...@redbarn.org wrote:
for the time being, and perhaps for a long time to come, the
people who call the presence of .PROD a bug and/or depend on its absence
as a
On 9/11/14 6:58 PM, Joshua Smith wrote:
Probably something I should know. But what's the best way to get notified of
new TLDs coming online to help arm the NOC?
https://gtldresult.icann.org/application-result/applicationstatus
hth,
Doug
___
On 9/11/2014 7:08 PM, Mark Andrews wrote:
...
I just wish I had been able to convince Paul to remove support for
partially qualified names back when RFC 1535 came out. We knew
then that they were a bad idea. ndots minimises the damage of using
partially qualified names. It doesn't
On 9/11/14 7:40 PM, Andrew Sullivan wrote:
On Thu, Sep 11, 2014 at 07:15:03PM -0700, Doug Barton wrote:
If you want a text list of TLDs that *is* updated in real time, you can use
this:
https://data.iana.org/TLD/tlds-alpha-by-domain.txt
Yes, but that's what's already in fact delegated, not
On Thu, Sep 11, 2014 at 07:48:27PM -0700, Doug Barton wrote:
Am I missing something here?
Only the point of the part of the message you elided in your response.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
dns-operations mailing
On 9/11/14 7:53 PM, Andrew Sullivan wrote:
On Thu, Sep 11, 2014 at 07:48:27PM -0700, Doug Barton wrote:
Am I missing something here?
Only the point of the part of the message you elided in your response.
Ok, so let's recap, to make sure I get the point. Because I like to,
yaknow, learn
On 9/11/2014 8:22 PM, Mark Andrews wrote:
In message 54125edc.6000...@redbarn.org, Paul Vixie writes:
On 9/11/2014 7:08 PM, Mark Andrews wrote:
...
I just wish I had been able to convince Paul to remove support for
partially qualified names back when RFC 1535 came out. We knew
then that
In message 541271ba.2000...@redbarn.org, Paul Vixie writes:
On 9/11/2014 8:22 PM, Mark Andrews wrote:
In message 54125edc.6000...@redbarn.org, Paul Vixie writes:
On 9/11/2014 7:08 PM, Mark Andrews wrote:
...
I just wish I had been able to convince Paul to remove support for
2014-09-11 21:02 GMT+04:00 Cathy Almond cat...@isc.org:
On 11/09/2014 13:38, Peter Andreev wrote:
Hello,
We run a public resolver and a few days ago I noticed a lot of very
weird queries, like the following:
16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A?
49 matches
Mail list logo
