SERVFAIL is a temporary error.
NXDOMAIN is a permanent error which is cachable.
SERVFAIL is not "fine".
Hmmn. Keeping in mind that these responses are sent by the cache, could
you explain what "cacheable" means in this context?
Applications can, and some do, cache responses.
No doubt, but
In message , "John R Levine" wri
tes:
> >> So a cache stub that provides unsigned answers to .local and .onion
> >> queries is just fine. If the client treats that as SERVFAIL or
> >> whatever it does with unverified answers, that's fine too.
> >
> > SERVFAIL is a temporary error.
> > NXDOMAIN is
So a cache stub that provides unsigned answers to .local and .onion
queries is just fine. If the client treats that as SERVFAIL or
whatever it does with unverified answers, that's fine too.
SERVFAIL is a temporary error.
NXDOMAIN is a permanent error which is cachable.
SERVFAIL is not "fine".
Hi,
Adding a few comments on this discussion, just one chair’s opinion:
The underlying question in this exchange seems to be what advice should this
document offer, and to whom?
This is a Working Group document, which means the decision about what’s in and
what’s out doesn’t rest with any indi
In message <20161019140954.31332.qm...@ary.lan>, "John Levine" writes:
> >You may not care that validating stub resolvers that ask for
> >example.local get back answers that can be validated as NXDOMAIN
> >without leaking queries to the root but I do. Just adding the zone
> >locally without havin
>You may not care that validating stub resolvers that ask for
>example.local get back answers that can be validated as NXDOMAIN
>without leaking queries to the root but I do. Just adding the zone
>locally without having the insecure delegation results in just that
>condition.
It just occurred to
>the discussions, the two biggest issues were the "governance"
>difficulties (adding DNAME records in the root...)
Nobody's mentioned the governaance issues, but speaking as someone who
spends too much time hanging around ICANN, that will be a huge can of
worms.
If we tell them that DNAMEs are
On 10/14/2016 05:09 PM, Stephane Bortzmeyer wrote:
> On Fri, Oct 14, 2016 at 10:04:21AM -0400,
> Paul Wouters wrote
> a message of 19 lines which said:
>
>> But by adding delegations in the root to AS112, aren't we making it
>> more likely that the queries leak further onto the net?
>
> That'
