On Nov 2 2011, Jan-Piet Mens wrote:
Note, the new .XXX TLD is included in that list.
Does that mean it is or isn't safe for work? ;-)
It depends on whether the XXX TLD acquires a signed delegation or not.
(Presumably it should, as you wouldn't want to get the *wrong* porn ...)
--
Chris Tho
On Wed, Nov 02, 2011 at 10:02:45AM -0400, wbr...@e1b.org wrote:
> But it does provide some alternatives:
>
> .intranet
> .internal
> .private
> .corp
> .home
> .lan
>
> But can we guarantee that they won't be approved as new public TLDs per
> the new rules adopted this summer where anything can
Bill Owens wrote on 11/02/2011 09:26:07 AM:
> I happened to be looking for some other details on mDNS yesterday
> and noticed that the current draft version of the spec reserves .local:
>
> http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-14
>This document specifies that the DN
> Note, the new .XXX TLD is included in that list.
Does that mean it is or isn't safe for work? ;-)
-JP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.i
On Wed, Nov 02, 2011 at 08:45:31AM -0400, wbr...@e1b.org wrote:
> Lyle wrote on 11/01/2011 04:19:18 PM:
>
> > Again, this has a disadvantage if they ever decide to make .internal a
> > real internet domain name and some people frown upon this practice. Be
> > sure you know what can go wrong.
>
On Wednesday 02 November 2011 08:00:55 Jan-Piet Mens wrote:
> > Is there an IETF/ICANN reserved TLD for internal use? I've seen
> > plenty of .loc and .local, but I haven't seen an RFC reserving
.local is used in MDNS, but AFAIK the RFC is still a draft.
> > it. RFC 2606 reserves .example, .inv
> Is there an IETF/ICANN reserved TLD for internal use? I've seen plenty of
> .loc and .local, but I haven't seen an RFC reserving it. RFC 2606
> reserves .example, .invalid, .localhost and .test but these don't seem
> approriate.
Not IETF/ICANN reserved, but ISO 3166 [1] reserves the follow
Lyle wrote on 11/01/2011 04:19:18 PM:
> Again, this has a disadvantage if they ever decide to make .internal a
> real internet domain name and some people frown upon this practice. Be
> sure you know what can go wrong.
Is there an IETF/ICANN reserved TLD for internal use? I've seen plenty of
On 1 Nov 2011 at 20:02, Phil Mayers wrote:
> On 11/01/2011 06:34 PM, Scott Morizot wrote:
>
> > Alternatively, you can sign 'policydomain.internal' and configure its key
> > as one of the trust anchors on the validating name servers. The order of
> > validation is, if I recall correctly, locally
On 11/1/2011 3:02 PM, Phil Mayers wrote:
On 11/01/2011 06:34 PM, Scott Morizot wrote:
Alternatively, you can sign 'policydomain.internal' and configure its key
as one of the trust anchors on the validating name servers. The order of
validation is, if I recall correctly, locally configured trust
On 11/1/2011 3:00 PM, Phil Mayers wrote:
On 11/01/2011 06:24 PM, Lyle Giese wrote:
A work-around (and it has some side effects and could be undesirable,
just be aware of the side effects of doing this) is to declare .internal
as a master zone in your DNS servers and then delegate
policydomain.i
On 11/01/2011 06:34 PM, Scott Morizot wrote:
Alternatively, you can sign 'policydomain.internal' and configure its key
as one of the trust anchors on the validating name servers. The order of
validation is, if I recall correctly, locally configured trust anchors,
then chain of trust from root, a
On 11/01/2011 06:24 PM, Lyle Giese wrote:
A work-around (and it has some side effects and could be undesirable,
just be aware of the side effects of doing this) is to declare .internal
as a master zone in your DNS servers and then delegate
policydomain.internal to your Windows AD servers in your
On 1 Nov 2011 at 18:12, vinny_abe...@dell.com wrote:
> Thanks, however I can't control the domain in question
> unfortunately. It is what it is. We have to work with it. I totally
> understand why this doesn't work and actually agree with the design,
> however I just don't have a workaround or way
On 11/1/2011 11:23 AM, Phil Mayers wrote:
On 01/11/11 16:14, vinny_abe...@dell.com wrote:
resolution fail since NXDOMAIN is the valid answer... done, end of
story. I thought the forwarder type would bypass this but apparently
I am wrong. Is there some other way to handle this for non-existent
d
s@lists.isc.org
Subject: Re: DNSSEC and forward zones
On 01/11/11 16:14, vinny_abe...@dell.com wrote:
> resolution fail since NXDOMAIN is the valid answer... done, end of
> story. I thought the forwarder type would bypass this but apparently
> I am wrong. Is there some other way to hand
On 01/11/11 16:14, vinny_abe...@dell.com wrote:
resolution fail since NXDOMAIN is the valid answer... done, end of
story. I thought the forwarder type would bypass this but apparently
I am wrong. Is there some other way to handle this for non-existent
domains just for testing purposes?
Don't d
17 matches
Mail list logo
