On 06.09.2013, at 10:49, Stephane Bortzmeyer wrote:
> On Thu, Sep 05, 2013 at 02:54:18PM -0700,
> Paul Vixie wrote
> a message of 68 lines which said:
>
>> Florian Weimer wrote:
>>>
>>> Because DNSSEC does not prevent cache poisoning, it only detects it.
>>
>> i do not understand this statem
On 06.09.2013, at 17:30, Edward Lewis wrote:
> On Sep 6, 2013, at 9:29, Daniel Kalchev wrote:
>
>> Or cache only after validation?
>
>
> I shudder to think there's an alternative. If you are going to cache anyway,
> don't waste your time validating.
&
On 14.10.13 19:08, Paul Hoffman wrote:
A fictitious 100-person company has an IT staff of 2 who have average IT
talents. They run some local servers, and they have adequate connectivity for
the company's offices through an average large ISP.
Should that company run its own recursive resolver
On 14.10.13 21:46, Doug Barton wrote:
We of the DNS literati tend to forget just how difficult this stuff
really is, and how hard it is for companies to prioritize spending
money on things that usually "just work." I can't count the number of
times I got "emergency" calls when I was consult
On 17.10.13 00:12, Jared Mauch wrote:
Even small networks (I have a friend with a ~100 user wisp) shouldn't run their
own caches. The economics of it don't support this.
Care to elaborate on this economic problem?
Just an reference point:
Most of today's smartphones already have more resour
On 21.10.13 02:52, David Conrad wrote:
On Oct 20, 2013, at 2:16 PM, Vernon Schryver wrote:
Should the people working on DNS implementations prioritize making
their DNSSEC code more robust and easier to use above or below
addressing your issues?
I'd say "below".
Resolver operators (hopefully)
On 22.10.13 12:50, Tony Finch wrote:
Vernon Schryver wrote:
Have you turned on DNSSEC where you can? If not, why not?
Can we have less of the ad hominem please.
I find these questions quite reasonable.
When one claims "DNSSEC is difficult", while other claim it is not, then
something i
On 23.10.13 22:17, Haya Shulman wrote:
Sorry for the brief description earlier, fyi, a slightly more
elaborate design:
The idea is to replace a single middle fragment, e.g., given n
fragments, for n>2, we replace some fragment, s.t., 1< i < n.
Assume n=3 (and also assume, for simplicity, that
On 26.10.2013, at 12:37, Haya Shulman wrote:
>> This is essentially an IP packet modification vulnerability and in order
>> to do these, you don't even need fragmentation. This might happen even
>> due to malfunctioning network adapter or other network device, not
>> necessarily an "attack". One
On 25.10.13 15:20, Stephane Bortzmeyer wrote:
On Tue, Oct 22, 2013 at 11:59:04PM +,
Vernon Schryver wrote
a message of 50 lines which said:
Why would there be extra support calls? Wrong keys are no worse
than wrong delegations
Of course, they are worse. In the vast majority of cases
On 29.10.13 13:31, Einar Lönn wrote:
On Oct 29, 2013, at 10:24 AM, Calvin Browne wrote:
I'm going to point out that .se went down because of a problem right at
this point relativly recently. And .ng and I think there were more..
--Calvin
No system is perfect until all human steps have
On 29.10.13 14:33, Einar Lönn wrote:
On Oct 29, 2013, at 12:51 PM, Daniel Kalchev wrote:
Furthermore this relatively tiny risk could be compared to the risk of a hijack
of a name server residing out-of-zone which silently captures X percent of all
your traffic. As you say you could consider
On 14.11.13 18:17, Peter Koch wrote:
On Thu, Nov 14, 2013 at 03:35:24PM +, Dan York wrote:
I wonder how much they will be able to sell "is.sexy" for?
last time I looked, Iceland still existed.
Was it not proven there is no problem... /s
Daniel
_
On 14.11.13 20:37, Dan York wrote:
Of course, when it will get really interesting will probably be in
January or so when General Availability hits for some of these and we
start seeing what levels of interest there really is in all these
newgTLDs.
That will be the true test for all "Universa
Like, you might get arrested if you ever visit Germany... Or Berlin.
Sent from my iPhone
> On 10.01.2014, at 23:13, "william.ehgo...@bell.ca"
> wrote:
>
> I'd like to see them enforce it when they are providing public, global
> records. ;)
>
> -W.
> --Original Message--
> From: Miek
This is apparently an bug in the RIPE Atlas probe management software — it
needs to make sure the probe can generally reach it’s own measurement targets,
before assigning it to do any public IPv6 measurements.
There are plenty of probes connected to misconfigured IPv6 networks all over
the worl
On 23.04.14 21:06, Stephane Bortzmeyer wrote:
On Mon, Apr 21, 2014 at 10:33:42AM +0300,
Daniel Kalchev wrote
a message of 165 lines which said:
This is apparently an bug in the RIPE Atlas probe management
software — it needs to make sure the probe can generally reach it’s
own measurement
On 11.09.14 21:51, Colm MacCárthaigh wrote:
> For example if a provider booted a box with an empty configuration, it
> would be much better to timeout queries than respond with SERVFAIL or
> REFUSED.
The protocol expects and response from the server. If no response, the
server is considered down
On 12.09.14 04:24, Andrew Sullivan 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
On 12.09.14 05:47, Paul Vixie wrote:
> in fairness, had we adopted the left-to-right presentation format
> preferred at first by our UK colleagues, we would have always had to
> write fully qualified names as .tld.sld.3ld, that is, the "root dot"
> would not have been optional, and there would ha
On 12.09.14 07:35, Mark Andrews wrote:
>
> In message <541271ba.2000...@redbarn.org>, Paul Vixie writes:
>>
>> like i said this seems insane now. mark was right, we should have broken
>> the bad stuff as early as possible.
>
> It isn't impossible. Emit warnings whenever a partially qualified
>
On 13.09.14 17:54, Phillip Hallam-Baker wrote:
> On Thu, Sep 11, 2014 at 9: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 absenc
>From the article:
“There’s no technical solution that Cloudflare can create to solve this
problem unless we re-architect the Internet.”
I just love this kind of thinking!
Daniel
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https:/
Obviously, e-mail authentication is not appropriate, as is any in-band
authentication as well.
Proper DNSSEC implementations should use end-to-end electronic signatures.
For example, while implementing DNSSEC back in 2007, we have made it
mandatory in the BG registry to use qualified electroni
On 18.07.12 19:30, Vernon Schryver wrote:
} From: Daniel Kalchev
} Obviously, e-mail authentication is not appropriate, as is any in-band
} authentication as well.
It's not clear to me that e-mail authentication using something like
https://www.ietf.org/id/draft-hoffman-dane-smime-0
On 23.09.12 03:53, Mark Andrews wrote:
Just because the DNS software did not prevent A, and MX records
being added does not mean that adding them was right.
Wish DNS software prohibited at least A and records for any domain
(zone), as opposed to "host" (this is largely indistinguis
On 21.09.12 19:02, Mike Jones wrote:
If apple decide that they want to use "apple." for their main website
then let them, it won't work, but it won't cause problems for anyone
except themselves and their users.
I would care less what it will cause to Apple and their users. That's
Apple's ta
On Oct 15, 2012, at 12:41 AM, Richard Lamb wrote:
> Why not the tpm migration method? I. E.
>
>
> The receiving hsm produces the public half of a master storage key.
> Then the starting hsm "authorizes" the key for use for exporting with pomp
> and circumstance ;-)
> Then the starting hsm e
On 19.10.12 00:57, Andrew Sullivan wrote:
When you delete names in EPP, you are not allowed to delete the name
if any subordinate host objects still exist. You cannot delete a host
object if there is something using that host object as a name server
(the host is linked).
Poor data model, th
On 06.12.12 06:29, Phil Pennock wrote:
Gmail offers what was, at the time they introduced it, an _unusual_
canonicalisation, which may have become more widespread now. It makes
a lot of sense. Gmail says that, for mail to one of their domains,
dots are not significant and canonicalise away. T
On 26.02.13 04:14, Warren Kumari wrote:
Now I realize that lots of folk would prefer to believe that there is
something more nefarious happening (and there is nothing really that I
can say to change that) but I figured I should at least try explain
why Google provides this...
It is of cours
Good example. I have argued for quite some time, that one of the DNSSEC primary
benefits is to fight misconfigurations. With DNSSEC an misconfigured domain
just "fails" instead of continuing to "work somehow".
There are lots of misconfigured domains on the Internet and plenty clueless DNS
admin
On 22.08.13 22:59, wbr...@e1b.org wrote:
From: Doug Barton
As stated before, the problem is that after the "early adopter" period
is over we'll be stuck with NTAs forever. This is one of those
fundamental disagreements between those who believe that DNS should
always be forgiving of operator er
On 23.08.13 00:37, Joe Abley wrote:
Last thing, we have NTAs today. People use them.
Local policy always prevails. Even over common sense. We observe this in
the real world, where local laws are always in force and in some places
the local laws might not make sense to us, or even irritate o
On 23.08.13 03:07, Vernon Schryver wrote:
From: Suzanne Woolf
I don't like it either, but it limits the damage done by a DNSSEC =
failure to status quo ante rather than something worse.
That is mistaken. You get the status quo ante by simply turning
off validation.
It seems, discussions li
On 23.08.13 18:12, Warren Kumari wrote:
On Aug 23, 2013, at 11:04 AM, "Carlos M. Martinez"
wrote:
I'm _very_ torn on the issue. On one hand I fully agree with Patrik in
the sense that documenting such practices could lead to widespread
'holes' in validation.
However, in my opinion the first
On 23.08.13 19:57, Ralf Weber wrote:
Moin!
On 23.08.2013, at 09:19, Paul Vixie wrote:
if nasa.gov had screwed up its delegation or had allowed its public secondary
servers to expire the zone due to primary unreachability, i do not think the
phone at comcast would have rung less, but i also
37 matches
Mail list logo
