y reserved.
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
specific RRs with
guessed rdata, within it.
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
own parent. They can't both be true.
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
suggested by the use of together, though.
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for any of its ancestors ?
Also, as such a response is undoubtedly still legal, maybe this ought
to mention what the common(er) practice now is - presumably REFUSED.
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https
-octet minimum overhead is
rather well known)
--
Chris Thompson University of Cambridge Information Services,
Email: c...@uis.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom
than 27 (and a lot
more detailed) although it still predates widespread use of anycast
in the DNS context.
Nothing has officially superceded RFC2182 and it remains a Best Common
Practice document (BCP0016).
--
Chris Thompson University of Cambridge Information Services,
Email: c
, but
it doesn't contain any sort of delegation for these address ranges.
What would be the right way to officially request IANA to do for
239.192.0.0/10 what Mark Andrews is proposing for 100.64.0,0/10?
At least in this case ARIN is not involved: 239.in-addr.arpa is
all IANA's own work!
--
Chris
to EMPTY.AS112.ARPA once that is available.
Would this last actually work to break the chain of trust (provided that
EMPTY.AS112.NET was itself unsigned)? I am having difficulty working out
exactly what a validator would do in this situation.
--
Chris Thompson University of Cambridge
and
blackhole-2.iana.org have no records? Is the idea to introduce new
names, or to add records to the existing names once there are enough
AS112 nodes advertising the IPv6 prefix?
--
Chris Thompson University of Cambridge Information Services,
Email: c...@uis.cam.ac.uk
as the _http._srv.[name] one. (The idea of https overriding
the port number(s) in the _http._srv.[name] records with 443 seems
too horrible to contemplate.)
--
Chris Thompson University of Cambridge Information Services,
Email: c...@uis.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue
. (Well,
they do as long as its official slaves are doing what we asked them to...)
All this is not because we are particularly concerned to keep the
zone contents secret. It's because they would be misleading.
--
Chris Thompson University of Cambridge Computing Service,
Email: c
On Dec 7 2013, Joe Abley wrote:
On 2013-12-05, at 07:15, Chris Thompson c...@cam.ac.uk wrote:
[...]
How would such DNAMEs interact with use of BIND's root-delegation-only
(or equivalents, if any, in other software)? Do we have any idea how
widespread use of that option is?
I don't recall
of that option is?
When ipv4only.arpa appeared as a delegation in October, I did wonder
why it wasn't just an A rrset in the arpa zone, until I thought of
that issue. Although maybe the reasoning was actually different.
--
Chris Thompson University of Cambridge Computing Service,
Email: c
, the IAB suggests the rollover of the Root Zone KSK
before the end of the year, with significant prior notice to all involved
parties, including vendors, implementors, TLD operators, and end-users.
I think we can be fairly confident *that* isn't going to happen... :-)
--
Chris Thompson
)?
Of course if the scheme goes ahead, EMPTY.AS112.ARPA itself becomes an
obvious candidate for such a local definition as well.
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United
be ignored.
That is, the chain of trust used by the parent to validate a CDS is
restricted to be of length 1. That is all it knows on earth, and all
it needs to know (with apologies to John Keats).
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.uk
contain RRs
of the same class.
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
___
DNSOP mailing list
DNSOP
is to generate
a negative answer to a reverse lookup. More to the current point
is that (unfortunately) few DNS registries support putting DNAMEs
in parent zones in place of delegations.
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site
, and BIND
gives me a NODATA response from its automatic empty zones that
cover just those specific addresses and no others, then it is
being unsafe?
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44
case if I could be sure that the updating of the
delegation could always be done in a timely fashion.
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom
in the delegation that points to a server that is not in fact
authoritative for the zone at all. Is the above actually common usage?
[That's not to say that any differences between the two NS RRsets is ever
desirable, except as may be necessary or expedient during a change.]
--
Chris Thompson
, the zones listed above will need to be delegated as
* insecure delegations, or be within insecure zones. This will allow
* DNSSEC validation to succeed for queries in these spaces despite not
* being answered from the delegated servers.
--
Chris Thompson University of Cambridge Computing
?
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
to worry about how to
update the DS records in the parent zone :-)
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom
and
child, but there could be problems with automatically updating glue.
The authoritative value of required glue may come from a grandchild
zone which is not signed, even if the child is, and sibling glue
could similarly involve unsigned zones.
--
Chris Thompson University
with a key for which the parent already
holds a DS record would be the appropriate modification. But is
this really necessary?
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United
of uk managed by Nominet, are more
recent examples.
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
___
DNSOP mailing
.
...
PTR 8.e.f.ip6.arpa.
PTR 9.e.f.ip6.arpa.
...
Not that this would stop some implementors fetching the current value
and fixing it in their code...
One would want local.zones.arpa (or whatever) to be signed, of course!
--
Chris Thompson
? Why shouldn't a chain of trust through (say) a KSK and a ZSK
be enough? Insisting on a one-step chain seems contrary to the
spirit, at least, of RFC 4034 section 2.1.1.
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site
imply NSEC3 support? If not, should we?
I suppose it is still open to DNSEXT to submit new algorithms which imply
NSEC only, but of course that is not expected to happen. (Anyway, 253 254
are 5 and there it's a matter for private agreement.)
--
Chris Thompson University of Cambridge
does sign it's name servers.
And indeed ns.se is in the se zone (no zone cut). But the consequence
is that a DO=1 priming query for se returns 2706 bytes while one for
. from the (DURZ-signed) root servers returns only 801 bytes.
--
Chris Thompson University of Cambridge Computing
On Oct 16 2009, Alfred Hönes wrote:
On Oct 16 2009, Chris Thompson wrote:
On Oct 16 2009, Alfred Hönes wrote:
Another point:
The draft is speaking abut DNAME _in_ the root.
According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected
with
KSKs rather than (the parent's) ZSKs?
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
___
DNSOP mailing list
: of course. But incremental policy improvements
would help meanwhile.
--
Chris Thompson University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom
how much do we have to charge Black Hat, Inc.
per key we crack for them, to make a decent profit?.
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
sure is why Philip Hazel
implemented the option in the first place.
Exim also provides the ability to use different retry rules in the
case when the target was found via an A or record, and these
are quite often used to give up (much) sooner on such deliveries.
--
Chris Thompson
Email: c
of browser guesswork (there is no address record for as112.net).
Not that I can get any response out of www.as112.net = 204.152.184.180
at the moment, either ... :-(
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https
long. On that basis, the trust anchor for the
root zone ought to be the DS record from Trantor.
--
Chris Thompson
Email: c...@cam.ac.uk
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
39 matches
Mail list logo
