In message , "Joe Abley" writ
es:
> On 27 May 2015, at 13:00, Mark Andrews wrote:
>
> > No. Just "different query - must be bad". "Different query - don't
> > know what to do -> drop" from firewall vendors.
>
> For an enterprise, given that there's no defined use, format (and
> therefore need)
In message <0cff2137-a8b7-44bb-a2a7-6bd3cd0db...@verisign.com>, "Wessels, Duane
" writes:
> > On May 27, 2015, at 10:32 AM, Joe Abley wrote:
> >
> > It's not obvious that this is a problem for anybody, though; it's not
> > like you'd expect to see a TLSA RRSet in there.
>
> Isn't this truly a pro
> On May 27, 2015, at 10:32 AM, Joe Abley wrote:
>
> It's not obvious that this is a problem for anybody, though; it's not like
> you'd expect to see a TLSA RRSet in there.
Isn't this truly a problem because if my cache is cold (for the zone in
question) my recursive name server
could send it
In message , "Joe Abley" writ
es:
>
>
> On 27 May 2015, at 16:16, Mark Andrews wrote:
>
> > Do we really have to fight to get every new type supported?
> >
> > Mark
> >
> > marka@ednscomp ~/tld-report]$ awk '$4 == "NS" {print $1, $5}' root.db
> > | sh gentypereport tlsa | grep -v "all ok"
> >
On Wed, May 27, 2015 at 3:59 PM, Shumon Huque wrote:
>
>>
>> Here's a transcript of my attempt to query all the NS addresses at
> accountant for TLSA records (from one location, a datacenter in New
> Jersey). Quick summary: no response/timeout from all the IPv4 addresses,
> correct NODATA answers
On Wed, May 27, 2015 at 3:40 PM, Warren Kumari wrote:
> On Wed, May 27, 2015 at 3:02 PM, Joe Abley wrote:
> >
> >
> > On 27 May 2015, at 19:14, Warren Kumari wrote:
> >
> >>> For what it's worth, I have no problem getting a reasonable (negative)
> >>> response to ACCOUNTANT/IN/TLSA or SOMETHING.
On Wed, May 27, 2015 at 3:02 PM, Joe Abley wrote:
>
>
> On 27 May 2015, at 19:14, Warren Kumari wrote:
>
>>> For what it's worth, I have no problem getting a reasonable (negative)
>>> response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
>>> 156.154.144.195 with EDNS0.DO=1 or without
On 27 May 2015, at 19:14, Warren Kumari wrote:
For what it's worth, I have no problem getting a reasonable
(negative)
response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special
:-)
Unable to parse.
Unsure why.
On Wed, May 27, 2015 at 1:32 PM, Joe Abley wrote:
>
>
> On 27 May 2015, at 16:16, Mark Andrews wrote:
>
>> Do we really have to fight to get every new type supported?
>>
>> Mark
>>
>> marka@ednscomp ~/tld-report]$ awk '$4 == "NS" {print $1, $5}' root.db | sh
>> gentypereport tlsa | grep -v "all ok
On 27 May 2015, at 16:16, Mark Andrews wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == "NS" {print $1, $5}' root.db
| sh gentypereport tlsa | grep -v "all ok"
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeo
Absolutely.
The technology is the easy bit. Deployment is the hard problem.
We are trying to make changes to a machine with ten billion components.
Every single one of which is more complex than the most complex machine
built before the moon landings and some of which are the product of more
huma
On May 27, 2015, at 6:16 PM, Mark Andrews wrote:
> Do we really have to fight to get every new type supported?
Is this a trick question?
The Empirical Evidence 8-ball would appear to say "Yes".
Regards,
-drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == "NS" {print $1, $5}' root.db | sh
gentypereport tlsa | grep -v "all ok"
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accoun
In message <22b1aa19-3a88-401d-bcae-0ebce2332...@arbor.net>, "Roland Dobbins"
writes:
> On 27 May 2015, at 19:00, Mark Andrews wrote:
>
> > Yes, EDNS compliance issues have been traced to scrubbing services and
> > firewalls.
>
> Competent DDoS scrubbing <> EDNS0 problems, FYI. If that's happe
On 27 May 2015, at 20:39, Roland Dobbins wrote:
I don't understand the bases behind the assumption that DDoS scrubbing
services are a factor in EDNS0 failure?
doh, it was pointed out to me that we're talking about EDNS(1), not
EDNS0. Apologies for my confusion.
I haven't seen any issues w
On 27 May 2015, at 20:24, Edward Lewis wrote:
I can accept that ... but are so many doing it so wrong that the
graphs are headed in the wrong direction?
I don't understand the bases behind the assumption that DDoS scrubbing
services are a factor in EDNS0 failure?
This statement:
On 27 May
On 5/27/15, 9:09, "Roland Dobbins" wrote:
>On 27 May 2015, at 19:00, Mark Andrews wrote:
>
>> Yes, EDNS compliance issues have been traced to scrubbing services and
>> firewalls.
>
>Competent DDoS scrubbing <> EDNS0 problems, FYI. If that's happening
>with some specific scrubbing service, it's b
On 27 May 2015, at 13:00, Mark Andrews wrote:
No. Just "different query - must be bad". "Different query - don't
know what to do -> drop" from firewall vendors.
For an enterprise, given that there's no defined use, format (and
therefore need) for EDNS(1), if your security posture is "default
On 27 May 2015, at 19:00, Mark Andrews wrote:
Yes, EDNS compliance issues have been traced to scrubbing services and
firewalls.
Competent DDoS scrubbing <> EDNS0 problems, FYI. If that's happening
with some specific scrubbing service, it's because those particular
organizations are Doing It
In message , Edward Lewis writes:
>
> Overall question. Looking at the chart on that URL, it seems like things
> are trending the wrong way, with the possible exception of the one
> well-performing bunch - the "Bottom 1000 Servers" [sic].
>
> Is that right? Excepting the one bump up on May 20,
In message , Edward Lewis writes:
>
> I'm reacting because I see a case of someone observing symptoms,
> presenting eye-catchy colorful pictures and then running hard into the
> land of diagnosis.
>
> On 5/27/15, 7:10, "Mark Andrews" wrote:
>
> >For others is is scrubbing / DoS services which
I'm reacting because I see a case of someone observing symptoms,
presenting eye-catchy colorful pictures and then running hard into the
land of diagnosis.
On 5/27/15, 7:10, "Mark Andrews" wrote:
>For others is is scrubbing / DoS services which are blocking EDNS(1)
>queries.
This sounds like the
Overall question. Looking at the chart on that URL, it seems like things
are trending the wrong way, with the possible exception of the one
well-performing bunch - the "Bottom 1000 Servers" [sic].
Is that right? Excepting the one bump up on May 20, it seems like things
are actually trending down
The jump up on May 20 was the EDNS(1) block being removed from
the Amazon Route 53 *.co.uk servers. Now for the other blocks
of servers to stop block EDNS(1) queries.
http://ednscomp.isc.org/compliance/ts/edns1resp.html
There are some TLD operators who could do the same.
Mark
--
Mark Andrews,
Thanks for all the helps.
Now I resolved the issues.
Just add the public IP of the VPS to named.conf below, restart bind and
it works.
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; 116.251.xx.xx; } keys { "rndc-key"; };
};
The kernel's routing may have problems, b/c
Hi Kevin
On Wed, May 27, 2015 at 04:13:55PM +0800, Kevin C. wrote:
> Hello,
>
> Can you tell me why this rndc run failed?
> # rndc reload
> rndc: connection to remote host closed
> This may indicate that
> * the remote server is using an older version of the command protocol,
> * this host is not
And running this also got failed.
# rndc -b 127.0.0.1 -s 127.0.0.1 -p 953 reload
The log shows,
named[1099]: rejected command channel message from 116.251.xx.xx#49422
I am strange why the request is from a public IP? (my named running on a
openvz VPS).
I am sure the key token both in rndc.c
Hello,
Can you tell me why this rndc run failed?
# rndc reload
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized, or
* the key is invalid.
28 matches
Mail list logo
