d with since we moved out of uucp naming has done this, and not
because I have told them to. Even current 20 person software house does
this. So, if you are going to substantially break search lists (which is
not inherently a bad idea - they have caused all sorts of trouble in times
past), you migh
list?
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
tions are either deprecating search lists
(or not supporting them), or supporting them properly, in
which case they must be used whatever domain name is
specified, and the way to avoid using a search list
is the same old hack as before (i.e. putting a dot on the
end).
--
Alex Bligh
--On 4 March 2010 19:53:52 -0800 Doug Barton wrote:
On 3/4/2010 4:31 PM, Alex Bligh wrote:
May be it's not a thick vs. thin distinction per se, but a "what happens
if registrant falls out with registrar" distinction. Thick registries
that have a direct contract with the
what happens
if registrant falls out with registrar" distinction. Thick registries
that have a direct contract with the registrant (e.g. Nominet) tend tob
be rather less willing to let a losing registrar intermeddle. May be
this is isomorphic to the beneficial ICANN involvement sugge
el, it would be possible for the registrant
to specify a DS key that the registry (rather than registrar) would
store, just like NS records are specified. So if the registrar changes,
there is no registrar involvement re DS keys unless they are deliberately
obnoxious.
"unhelpful." At least in the case of the gTLD
registrars this is an area where ICANN intervention is likely to be
required, and may actually be beneficial.
Partly depends on thick vs. thin registry model though.
--
Alex Bligh
___
DNSOP mailing
N TXT "[DSKEY]:[HASH]"
where [HASH] is a truncated hash of the DS key and a secret shared
(once) between registrar/y and the registrant/DNS operator. Obviously
the record needs to then pass the normal signing checks too. If it
doesn't check out, the previous DS
mmediately
see how without some external authentication (yet another key) you
can securely automatedly push DS key changes about.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ull is
in place?
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
on
to choose between NSEC and NSEC3 and as such are irrelevent.
Oh I don't know. I think it could be argued NSEC3 is more likely to
drive people to drink than NSEC ... :-)
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailma
--On 22 February 2010 09:05:47 -0800 Eric Rescorla wrote:
On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends wrote:
On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote:
Alex Bligh wrote:
Using NSEC instead of NSEC3 because you fear SHA1 collisions does not
seem sensible ... And it isn't sensib
f DNSSEC is predicated on similar
qualities.
Note the current draft already recommends NSEC if you don't need
NSEC3 (for reasons other than fear of hash collisions). I am entirely
happy with that.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.or
ovide
proof of non-existence (and in the case of NSEC3 opt out, not
even that).
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for" means "for that"
and is archaic)
The NSEC3 hashing includes the FQDN in its uncompressed form. This
"over its uncompressed form"? The hash does not 'include' it.
how about "the NSEC3 hash is performed over data including the FQDN in its
uncompressed form&q
nt further and said it should
only apply to large delegation-only/mostly zones where secure
delegations were sparse).
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--On 23 January 2010 04:56:33 + Alex Bligh wrote:
Having verifiable deniability for typo-squated domaims is very useful.
If expensive, where 99% of your domains are unsigned.
By which I mean expensive given this isn't the cheapest attack vector.
If I want to typo squat with
eadilly available.
Sure. Just rehearsing an argument I've heard others use against NSEC3.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
he delegation itself) are spoofable
with or without opt-out. Paul's example of a secure delegation
with opt-out across it can't exist.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e zone, that's a problem
for the implementor rather than the operator.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
egular" is "never"?
There seems to be some confusion of "regular" and "frequent" too.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y the poster child for this.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
gations, given if a spoof can be done, it can be
done at the delegated zone level. There are considerable operational
advantages in Opt Out (zone size, cryptographic complexity etc.)
for large zones only sparsely populated with secure delegations,
particularly where few queries have DO s
--On 13 January 2010 21:35:48 + Alex Bligh wrote:
Sure, clients should as a general rule try getting UDP to work, but
I think preventing them falling back to UDP unless they are prepared
^^^ - TCP
to take the overhead of adding DO set is not
--On 13 January 2010 21:16:49 + Jim Reid wrote:
On 13 Jan 2010, at 20:49, Alex Bligh wrote:
Current operational practice would result in DO clear packets
fitting within 4096 bytes, so no need for TCP when DO is clear.
I don't think that's always the case Alex. See t
ng TCP
is probably a bit harsh given we don't even know they have UDP
connectivity. Perhaps "MUST issue the priming query *first*
over UDP", or use a SHOULD.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--On 13 January 2010 19:19:40 + Jim Reid wrote:
Priming queries from DNSSEC-ignorant resolvers
An EDNS0 ignorant resolver MUST issue the priming query over UDP.
I presume you mean DNSSEC ignorant.
--
Alex Bligh
___
DNSOP mailing list
DNSOP
queries over TCP; in these instances the response
packet would be much smaller.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
owever, testing the new
nameservers work before installing them is probably not a bad idea,
just in case the proxy tries to be "helpful" by transparently intercepting
DNS packets not addressed to it (as a small minority of the proxies
you te
ptions, e.g. DO set and so forth), and
check the reply looks sensible. If not, it doesn't use it. That way it
doesn't use any server that makes things worse. The query could be an NS
query for ".", but perhaps better a fixed records in .ARPA that does exist
& is signed.
--
ies. Bypass them, and DNSSEC becomes easier to deploy,
in which case we have a weapon against DNS manipulation (I appreciate
there are arguments that this weapon is less than perfect, but it
is currently the best weapon we have).
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
condly, all you "win" is the ability
to spoof insecure queries. However, it would be possible to
avoid even this, e.g. with a nonce in the QNAME.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
rrent
protocol only requires a configuration change. I shall
think about this.
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
33 matches
Mail list logo
