On Sat, Apr 15, 2023 at 11:20:13AM +1000, Mark Andrews wrote:
> At this stage I think the only way to force this is to drop negative
> responses without SOA records present. To have the lookups fail and
> that requires buy in by the large recursive server operators.
>
> Similarly add an unknown E
At this stage I think the only way to force this is to drop negative
responses without SOA records present. To have the lookups fail and
that requires buy in by the large recursive server operators.
Similarly add an unknown EDNS option (pick a value between 1000 and 1999)
to every QUERY until 1 J
Somehow saying MUST include a SOA record in the negative response
isn’t enough.
3 - Negative Answers from Authoritative Servers
Name servers authoritative for a zone MUST include the SOA record of
the zone in the authority section of the response when reporting an
NXDOMAIN or indicating that no d
Also the following section (2.2.1 - Special Handling of No Data)
suggests sending type 2 instead of type 1 responses but is silent
about type 3 responses.
On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood wrote:
>
> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews wrote:
> >
> > RFC 2038 already says add
On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews wrote:
>
> RFC 2038 already says add the SOA so negative answers can be cached. The
> other responses
> where to show what was out there so that they where not misinterpreted.
I believe you are referring to this sentence? Quote: "The authority
section
RFC 2038 already says add the SOA so negative answers can be cached. The other
responses
where to show what was out there so that they where not misinterpreted. I doubt
saying
don’t do those old forms will make any difference. Everything out there has
had 25 years
to comply.
> On 15 Apr 2023,
Though this is in fact implicit in RFC4035 Section 6.2, it is perhaps
worth reminding any implementors reading this post (and though absurdly
late, perhaps even adding yet another minor tweak to the document) that
the target name of a SVCB or HTTPS record, though a domain name, MUST
NOT be canonica
On the topic of authoritative server behavior as seen in the DNS
responses, a few areas for improvement below (not touching DNSSEC).
This is written from the perspective of a resolver using the auth
responses to answer user queries.
* responding correctly to requests with certain flags, EDNS optio
I wanted to respond to this thread earlier, so apologies in advance
for late posting and if this is a no-op at this point. Me getting
confused about the last call for this draft
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/)
and https://datatracker.ietf.org/doc/draft-ietf
