In article you
write:
>David Conrad wrote:
>
>> To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or
>> wildcards).
>
>Wildcards are being used for the name collision gubbins.
>;; ANSWER SECTION:
>*.prod. 3600IN A 127.0.53.53
Yes, but only for a
On Sep 19, 2014, at 2:01 AM, Tony Finch wrote:
> David Conrad wrote:
>> To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or
>> wildcards).
> Wildcards are being used for the name collision gubbins.
Ah, true. Apologies. There is a waiver from that restriction exclusively for
th
David Conrad wrote:
> To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or
> wildcards).
Wildcards are being used for the name collision gubbins.
; <<>> DiG 9.11.0pre-alpha <<>> *.prod
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51
On Sep 17, 2014, at 6:01 PM, Jimmy Hess wrote:
> On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth wrote:
>
>> The latter would seem to be avoidable by making sure that *DNS resolution
>> of bare TLDs always returns NXDOMAIN*.
> [snip]
>
> Not NXDOMAIN.When TLD. is looked up, they should
On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth wrote:
> The latter would seem to be avoidable by making sure that *DNS resolution
> of bare TLDs always returns NXDOMAIN*.
[snip]
Not NXDOMAIN.When TLD. is looked up, they should always return NOERROR.
And yield, either (1) the NS recor
On Thu, Sep 18, 2014 at 07:39:08AM +1000, Mark Andrews wrote:
> You want gethostbyname, getaddrinfo to return HOST_NOT_FOUND/EAI_NONAME
I was unaware that getaddrinfo returned "NXDOMAIN", which is what I
read in the thread being talked about. Not return values from the OS
calls. I guess I misse
Doug Barton wrote:
> In the case
> you specify you get the combination of NOANSWER + NOERROR
> if there is no address record, but there are other records
> (like there are at a zone apex).
valdis.kletni...@vt.edu wrote:
> NXDOMAIN means "There are no records of *any* type at that node".
Not.
T
Fred,
On Sep 17, 2014, at 3:04 PM, Fred Baker (fred) wrote:
> IMHO, since ICANN has created the situation,
ICANN has created ill-specified domain search path heuristics and truly
fascinating implementations of those heuristics? ICANN has caused people to
use non-allocated TLDs in environment
In message <21906507.2046.1410990673107.javamail.r...@benjamin.baylink.com>, Ja
y Ashworth writes:
> - Original Message -
> > From: "Mark Andrews"
>
> > Search lists are for hosts and host like things. Resolver libraries
> > have different interfaces for different purposes. Single label
IMHO, since ICANN has created the situation, the ball is in ICANN’s court to
say how this works without disrupting name services. Their ill-informed hipshot
is not our emergency.
On Sep 17, 2014, at 9:09 AM, Jay Ashworth wrote:
> Pursuant to
>
> https://www.icann.org/resources/pages/name-col
- Original Message -
> From: "Doug Barton"
> > I want to return NXDOMAIN *because there is no record of that type
> > at that node*.
> >
> > That was the underlying point here; I thought that was pretty clear.
>
> But that's not what NXDOMAIN means. :) You get an NXDOMAIN response
> when
On Wed, 17 Sep 2014 17:48:58 -0400, Jay Ashworth said:
> I want to return NXDOMAIN *because there is no record of that type at that
> node*.
NXDOMAIN means "There are no records of *any* type at that node".
NOERROR means "There are no records of *that* type at that node (but the
node exists and
On 9/17/14 2:48 PM, Jay Ashworth wrote:
- Original Message -
From: "Andrew Sullivan"
On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
- Original Message -
No, I was confusing you for someone who understood -- as everyone else
here seems to have -- that I meant "
- Original Message -
> From: "Mark Andrews"
> Search lists are for hosts and host like things. Resolver libraries
> have different interfaces for different purposes. Single label
> hostnames for reaching non local equipment was deliberately phase
> out in the 1980's as it was clearly a ba
- Original Message -
> From: "Andrew Sullivan"
> On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
> > - Original Message -
> > No, I was confusing you for someone who understood -- as everyone else
> > here seems to have -- that I meant "querying for an A, , or MX
In message <20140917211336.gt89...@dyn.com>, Andrew Sullivan writes:
> On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
> > - Original Message -
> > No, I was confusing you for someone who understood -- as everyone else
> > here seems to have -- that I meant "querying for an A
On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
> - Original Message -
> No, I was confusing you for someone who understood -- as everyone else
> here seems to have -- that I meant "querying for an A, , or MX
> record".
You want to return NXDOMAIN for a name only when th
- Original Message -
> From: "John Levine"
> >The latter would seem to be avoidable by making sure that *DNS resolution
> >of bare TLDs always returns NXDOMAIN*.
> >
> >Is that a requirement for a TLD?
>
> No. In fact, a TLD lookup that returned NXDOMAIN would be utterly
> broken since t
>The latter would seem to be avoidable by making sure that *DNS resolution
>of bare TLDs always returns NXDOMAIN*.
>
>Is that a requirement for a TLD?
No. In fact, a TLD lookup that returned NXDOMAIN would be utterly
broken since that would mean the TLD had no SOA, no NS, and no
subdomains. Perha
On Sep 17, 2014, at 11:08 AM, Eric Brunner-Williams wrote:
> On 9/17/14 10:45 AM, David Conrad wrote:
>> To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or
>> wildcards).
> um. .museum. …
.MUSEUM gave up their wildcard some time ago.
Regards,
-drc
signature.asc
Description
On 9/17/14 10:45 AM, David Conrad wrote:
To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or wildcards).
um. .museum. ...
- Original Message -
> From: "David Conrad"
> > A records being returned for bare TLDs *is* formally banned?
> >
> > (Oh: specifically for cctlds. Got it.)
>
> To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or
> wildcards). ICANN has no mechanism by which policy can be
Jay,
On Sep 17, 2014, at 10:36 AM, Jay Ashworth wrote:
> We're talking, largely, about error cases *that used to break as you wanted,
> and now might not*.
Yep. Well, it used to break if you happened to be using the right version of
resolver library. There have been cases where operating syst
On 9/17/14 10:36 AM, Jay Ashworth wrote:
A records being returned for bare TLDs*is* formally banned?
(Oh: specifically for cctlds. Got it.)
No, ICANN doesn't ban anything for the ccTLDs.
Citation?
The gTLD registry contracts describe the fact that they cannot add A
records at the zone
Original Message -
> From: "David Conrad"
> A common case of name collision is driven by the “DNS search path”,
> e.g., if you have a “search path” of “bar.com;foo.bar.com” and you
> type “telnet baz”, _some_ resolver libraries will try to resolve
> “baz.bar.com”, if that fails then “baz
Jay,
On Sep 17, 2014, at 9:09 AM, Jay Ashworth wrote:
> it seems there are two major potential points of possible collision:
>
> 1) User network uses "fake" TLD which is no longer fake, and local
> resolver server blows it
>
> 2) User network blows it worse, and tries to resolve a monocomponen
Pursuant to
https://www.icann.org/resources/pages/name-collision-2013-12-06-en)
mentioned in the Scotland thread... it seems there are two major potential
points of possible collision:
1) User network uses "fake" TLD which is no longer fake, and local
resolver server blows it
2) User network
27 matches
Mail list logo
