On Oct 25 2013, Andrew Sullivan wrote:
On Thu, Oct 24, 2013 at 10:53:03PM +, Wolfgang Nagele wrote:
Why would this be unsafe and/or fragile? As was already mentioned
the root zone has to include glue for whichever name you choose
anyway, due to the position in the hierarchy
This isn't s
On Thu, Oct 24, 2013 at 09:11:41AM +0300,
Daniel Kalchev wrote
a message of 247 lines which said:
> This is not an attack on DNS, but an attack on IP reassembly
> technology.
Frankly, I do not share this way of seeing things. Since the DNS is,
by far, the biggest user of UDP and since TCP is
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, lame
delegations (or other mistakes) do not
On Tue, Oct 22, 2013 at 01:28:15PM -0700,
Paul Vixie wrote
a message of 24 lines which said:
> BIND9 V9.9 may surprise you. it has inline signing and automatic key
> management.
I don't think it is a fair description of BIND 9.9 abilities. It does
not manage keys (which, IMHO, mean creating t
> xn--ngbc5azd. 172800 IN NS a.nic.xn--ngbc5azd.
> xn--ngbc5azd. 172800 IN NS b.nic.xn--ngbc5azd.
> xn--ngbc5azd. 172800 IN NS c.nic.xn--ngbc5azd.
> xn--ngbc5azd. 172800 IN NS d.nic.xn--ngbc5azd.
> a.nic.xn--ngbc5azd. 172
> From: Stephane Bortzmeyer
> > 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, lame
> delegations (or other mistakes) do not prevent resolution (as long as
> one name server works). A wrong
On Oct 25, 2013, at 3:45 PM, Randy Bush wrote:
>> xn--ngbc5azd.172800 IN NS a.nic.xn--ngbc5azd.
>> xn--ngbc5azd.172800 IN NS b.nic.xn--ngbc5azd.
>> xn--ngbc5azd.172800 IN NS c.nic.xn--ngbc5azd.
>> xn--ngbc5azd.
Randy,
On Oct 25, 2013, at 9:45, Randy Bush wrote:
> the ip address clumping would worry me if i thought they were not anycast.
Anycast or not, I wouldn't think this is a problem. Meaning, I don't see why
this would be a problem with unicast. Assuming that (for v4) the /24's are
independent
Chris Thompson
Friday, October
25, 2013 03:58
On Oct 25 2013, Andrew Sullivan
wrote:
That depends on whether you think including "sibling glue" [*] is
mandatory, or at least advisable. All NS records for TLD delegations
involve either "required glue" if the name is insid
On Oct 25, 2013, at 1:33 PM, Edward Lewis wrote:
> Randy,
>
> On Oct 25, 2013, at 9:45, Randy Bush wrote:
>
>> the ip address clumping would worry me if i thought they were not anycast.
>
> Anycast or not, I wouldn't think this is a problem. Meaning, I don't see why
> this would be a proble
Hi Stephane,
> > BIND9 V9.9 may surprise you. it has inline signing and automatic key
> > management.
>
> I don't think it is a fair description of BIND 9.9 abilities. It does
> not manage keys (which, IMHO, mean creating them as necessary, remove
> them when outdated, change them intelligently d
11 matches
Mail list logo
