On Fri, Sep 12, 2014 at 02:35:37PM +1000, Mark Andrews wrote:
>
> "WARNING: The partially qualified name '%s' resulted in a search
> list match. The use of partially qualified names is a unsafe
> practice. Fix your configuration to use the fully qualified name
> '%s'."
>
> Linux developers do s
On Thu, Sep 11, 2014 at 08:42:45PM -0700, Doug Barton wrote:
> 3. You respond with the same URL, plus pontification on various topics,
If by "pontification on various topics" you mean "the bit about how
the new gTLD database actually can tell you what stuff has passed all
the hurdles, even if it's
2014-09-11 21:02 GMT+04:00 Cathy Almond :
> 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.ww
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 remo
On 12 sep 2014, at 04:08, Mark Andrews wrote:
> The real fix is make the resolver libraries not append search lists
> entries to names with multiple labels. Yes, people need to type
> slightly long names or add more search list entries. Yes there
> will be some pain but it is something better d
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
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 stuf
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 they were a bad idea.
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 l
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 wh
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 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 what is about to
(so it's the same as jus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Here:
https://mm.icann.org/mailman/listinfo/gtldnotification
- - ferg
On 9/11/2014 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?
>
> -- J
On 9/11/2014 6:12 PM, Paul Hoffman wrote:
> On Sep 11, 2014, at 4:27 PM, Paul Vixie 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 feature, outnumbers and will outnumber the people who ca
On 9/11/14 7:10 PM, Andrew Sullivan wrote:
Probably the_best_ way is to get copies of the root zone. There's
alsohttp://newgtlds.icann.org/en/program-status/delegated-strings,
but it explicitly says that it's not being updated in real time.
If you want a text list of TLDs that *is* updated in
In message <5411cb74.8090...@easydns.com>, "Mark E. Jeftovic" writes:
>
> 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 whil
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
___
dns-ope
In message <45b62715-b7f9-439e-81b3-6c7356e88...@vpnc.org>, Paul Hoffman writes
:
> On Sep 11, 2014, at 4:27 PM, Paul Vixie 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 feature, out
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 http://newgtlds.icann.org/en/progr
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 wrote:
>
>
>> On 9/11/2014 6:
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:
>> .
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 Sep 11, 2014, at 4:27 PM, Paul Vixie 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 feature, outnumbers and will outnumber the people who call it a
> feature or who will call its absence a
On 9/11/2014 5:22 PM, Colm MacCárthaigh wrote:
> On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews 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
> 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 w
> 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 logi
On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews 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 for custome
In message
, =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writes:
> On Thu, Sep 11, 2014 at 4:28 PM, Mark Andrews wrote:
> > Actually timeout is much, much, much worse.
>
> When I experiment empirically there seem to be caches that will fail
> the resolution if one of the auth servers returned REFUSED or
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 n
In message
, =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writes:
> On Thu, Sep 11, 2014 at 9:46 AM, Andrew Sullivan wro
> te:
> > Also, it's not like it's terrifically onerous, although I know some
> > registrars' web interfaces for this are messy and confusing.
>
> I do think that the policies of the .
On Thu, Sep 11, 2014 at 4:28 PM, Mark Andrews wrote:
> Actually timeout is much, much, much worse.
When I experiment empirically there seem to be caches that will fail
the resolution if one of the auth servers returned REFUSED or
SERVFAIL. Different numbers for each, but both trigger it. Meanwhil
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 nev
> 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
On 11 September 2014 09:52, Mark E. Jeftovic wrote:
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <5411d5b6.8090...@isc.org>, Cathy Almond
writes
>There's a lot of this about.
I agree ... and I have some extensive measurements of it
>We did awhile back wonder if it was botnet-related, but I've not (yet)
>seen any persuasive evidence
On Thu, Sep 11, 2014 at 9:46 AM, Andrew Sullivan
wrote:
> Also, it's not like it's terrifically onerous, although I know some
> registrars' web interfaces for this are messy and confusing.
I do think that the policies of the .is GLTD are a net harm for DNS.
They require that DNS servers respond
> 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 h
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 t
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 91.209
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 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
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 efficien
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
On Thu, 11 Sep 2014 12:19:00 -0400
"Mark E. Jeftovic" 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 don't think this
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 r
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 Bortzmeye
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 migh
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
> 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? izhsccxedub.www.feile666.com. (57)
>
Probably some type of obfuscated C&C communication or way for a botnet owner
On Thu, Sep 11, 2014 at 07:52:31AM -0700,
Colm MacCárthaigh 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, too :-)
___
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
http://www.b
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 :
> On Thu, Sep 11, 2014 at 04:38:25PM +0400,
> Peter Andreev wrote
> a message of 29 lin
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
On Sep 11, 2014, at 9:46 PM, Stephane Bortzmeyer 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.]
Yes. The blac
On Thu, Sep 11, 2014 at 09:00:37PM +0800,
Roland Dobbins 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 considering investigating
-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 NetSu
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 opt
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
On Thu, Sep 11, 2014 at 04:38:25PM +0400,
Peter Andreev 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 IP 91.209.124.75.5
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.
Power
On Sep 11, 2014, at 8:42 PM, Peter Andreev 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 a
reflection/amplifi
On Sep 11, 2014, at 8:42 PM, Peter Andreev 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 the placement
of the p
-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
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? izhsccxedu
On 11 Sep 2014, at 3:54, Keith Mitchell 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 window ?
I tried m
On 09/10/2014 01:57 PM, Peter Losher wrote:
> On 10 Sep 2014, at 10:50, Joe Abley wrote: Sorry for the non-op
> question, but Keith's autoresponder says he's busy at UKNOF in
> Belfast and I've unfortunately left all this room booking to the
> last minute.
Please can you use for all OARC suppor
66 matches
Mail list logo
