Hi,
My nohats.ca domain has been under a couple of weeks long ANY attack. I
assume spoofed IPs querying open resolvers that in have their upstream
DNS send me queries.
The vast majority of queries are coming from Google's many IP addresses.
While I understand it must be an impressive ANYCAST ne
On Wed, Aug 6, 2014 at 11:10 AM, Paul Wouters wrote:
>
> Hi,
>
> My nohats.ca domain has been under a couple of weeks long ANY attack. I
> assume spoofed IPs querying open resolvers that in have their upstream
> DNS send me queries.
>
> The vast majority of queries are coming from Google's many I
On Wed, Aug 6, 2014 at 11:33 AM, Casey Deccio wrote:
> Google's implementation seems to recursively query for and cache ANY based
> on the entire set of records for the same name, rather than on a per-record
> basis. nohats.ca includes an NSEC3PARAM record with TTL 0. This results
> in zero cac
* Paul Wouters wrote:
> It seems that the nsd ratelimits to send TC=1 isn't working well either
> to reduce the incoming amount of UDP queries.
>
> Why does google dns seems so inefficient at caching?
I can second this. With rate limiting and dampening (at my side) I get
customer complains, that t
On Wed, 6 Aug 2014, Casey Deccio wrote:
Why does google dns seems so inefficient at caching?
Google's implementation seems to recursively query for and cache ANY based on
the entire set of records for the same name,
rather than on a per-record basis. nohats.ca includes an NSEC3PARAM rec
From everything I know, this is wrong and it's apparently making our
nameservers give inconsistent results. What nameserver allows
this and what might they be attempting to accomplish?
John Wobus
Cornell University IT
dig +norecurs mx cjsarchitects.com @dns3.name-services.com.
; <<>> DiG 9.4.
John Wobus writes:
> From everything I know, this is wrong and it's apparently making our
> nameservers give inconsistent results. What nameserver allows
> this and what might they be attempting to accomplish?
It is wrong, and what they're attempting to accomplish is to hand over
their "naked" d
On Wed, Aug 06, 2014 at 02:15:15PM -0400, John Wobus wrote:
> From everything I know, this is wrong
Yep.
> and it's apparently making our
> nameservers give inconsistent results.
Doubtless.
> What nameserver allows this
Several, every one of which apparently has to re-learn this.
> and what
On Wed, 6 Aug 2014, Casey Deccio wrote:
Why does google dns seems so inefficient at caching?
Google's implementation seems to recursively query for and cache ANY based on
the entire set of records for the same name,
rather than on a per-record basis. nohats.ca includes an NSEC3PARAM rec
In message <20140806191927.gt37...@mx1.yitter.info>, Andrew Sullivan writes:
> On Wed, Aug 06, 2014 at 02:15:15PM -0400, John Wobus wrote:
> > From everything I know, this is wrong
>
> Yep.
>
> > and it's apparently making our
> > nameservers give inconsistent results.
>
> Doubtless.
>
> > Wh
We are working on a DNS consistency check tool tool and a component
includes checking several public recursive name servers for the latest
SOA/A/ records and TTLs. The zones we publish often have TTLs
measured in the 7+ day range, changes are incredibly low volume, and
we always plan on waiting
Who is we?
Why are we allowing role accounts to subscribe here?
Who is intdnsops?
On August 6, 2014 3:24:39 PM PDT, intdnsops intdnsops
wrote:
>We are working on a DNS consistency check tool tool and a component
>includes checking several public recursive name servers for the latest
>SOA/A/AAA
On Thu, Aug 07, 2014 at 07:51:53AM +1000, Mark Andrews wrote:
> Those with developers that don't read RFC 1034 which tried to prevent
> this from happening.
You're probably right. But of course, RFC 1034 was written a number
of years ago, and some of the protocol-specification language that
later
we all said symlinks were a bad idea when Berkeley did them. We also all
use them. The properties OF the symlink matter more than people realize,
because 99% of the time, they care about the properties of the object
pointed to by the symlink.
when Sun added ${symbolic} expansion on the fly to syml
>What nameserver allows this
Several, every one of which apparently has to re-learn this.
Hi,
I saw Amazon Route53 has allowed this also. does it mean route53 is
broken? thanks.
--
We are hiring cloud Dev/Ops, for more details please see:
http://soa.game.yy.com/jobs.html
No. They're doing it by simulating it. The actual dns responses are a or
records. It only works under some circumstances.
A
--
Andrew Sullivan
Please excuse my clumbsy thums.
> On Aug 6, 2014, at 21:10, Yonghua Peng wrote:
>
>
>>> >What nameserver allows this
>> Several, every on
Andrew Sullivan wrote:
> No. They're doing it by simulating it. The actual dns responses are a or
> records. It only works under some circumstances.
my view of the cname-precludes-other-data rule is that it's always been
clear. protocol engineering means figuring out what other complia
The grain of sand that causes this pearl is that TLDs won't just publish the
CNAME without delegation.
That is all...
--
Fred Morris
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-ope
In message <201408061907.32371.m3...@m3047.net>, Fred Morris writes:
> The grain of sand that causes this pearl is that TLDs won't just publish the
> CNAME without delegation.
>
> That is all...
Even if they do allow publishing CNAMEs it doesn't solve the issue
for many as what they really want
On Wed, Aug 6, 2014 at 7:16 PM, Paul Vixie wrote:
> the now-common CDN trick of inventing a nonstandard "ALIAS" record or
> similar, that causes the authority server to recurse for any qtype
> that's not actually present in the zone, and to report that recursive
> data as authoritative, does not c
On August 6, 2014 9:08:34 PM PDT, "Colm MacCárthaigh" wrote:
>On Wed, Aug 6, 2014 at 7:16 PM, Paul Vixie wrote:
>> the now-common CDN trick of inventing a nonstandard "ALIAS" record or
>> similar, that causes the authority server to recurse for any qtype
>> that's not actually present in the zo
21 matches
Mail list logo
