Re: [Last-Call] draft-ietf-add-resolver-info-10 is no implementable as stands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Having had a look to see what this is about, then firstly I agree with Mark's comments here, but additionally I don't quite understand why a new RRType is needed rather than expanding on the work already done in RFC 9641.

It would seem to me that a DNS client needing to know information about a DNS server would need to use the SVCB record, so it feels intuitively as if the additional information here would be better placed in the same record, eliminating the need for two different queries.

Happy (and eager) to be corrected, of course.

Dave.

On Tue, 20 Feb 2024 at 22:34, Mark Andrews <marka@xxxxxxx> wrote:

As an additional note why is putting the answer into the authority
section needed at all?  Just look for AA=1 in the response.  Recursive
responses have AA=0.  The resolver is supposed to be authoritative for
the name and the RRset.

Additionally if you don’t want a recursive response, don’t ask for one.
Set RD=0 in the request.

Mark


> On 21 Feb 2024, at 09:15, Mark Andrews <marka@xxxxxxx> wrote:
>
>
>
>> Begin forwarded message:
>>
>> From: Mark Andrews <marka@xxxxxxx>
>> Subject: draft-ietf-add-resolver-info-10 is no implementable as stands
>> Date: 20 February 2024 at 11:36:30 AEDT
>> To: ietf <ietf@xxxxxxxx>
>>
>>
>> draft-ietf-add-resolver-info-10 changes the standard DNS QUERY processing
>> failed to specify what happens when the QNAME is NOT the name that is
>> supposed to be used with the resolver.
>>
>> "The content of the RDATA in a response to a RESINFO RR type query is
>> defined in Section 5. If the resolver understands the RESINFO RR
>> type, the RRSet in the Authority section MUST have exactly one
>> record. The RESINFO in the Authority section reflects that the
>> RESINFO is a property of the resolver and is not subject to recursive
>> resolution.”
>>
>> There is no “Updates: RFC 1034” which this clearly does.  There is no
>> description of the changes to RFC 1034. 
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@xxxxxxx
>>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@xxxxxxx
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@xxxxxxx

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux