Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 2 July 2018 at 00:03, Paul Hoffman wrote >8 > Well, RFC 1035 *does* say that it is in ASCII, whether we like that or not. Perhaps we need to remind ourselves what RFC1035 actually *does* say. ASCII is mentioned in three places only: 2.3.3 para 1, initially about case-insensitive character string comparisons, but then wanders off-topic: However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided. 3.1 para 3, supposedly dealing with preferred name syntax, also has another crack at case-insensitive comparisons: Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly. 6.1.2 para 3, in a section dealing with nameserver internal data structures, yet again gets fixated on character case issues: One way to solve the case problem is to store the labels for each node in two pieces: a standardized-case representation of the label where all ASCII characters are in a single case, together with a bit mask that denotes which characters are actually of a different case. 3.1 para 1, dealing with domain names in DNS messages, which being an external interface, one might expect character encoding to be specified, does not mention ASCII at all. Furthermore, in the whole of section 5, which specifies the format of master files, there is no mention of the character encoding of the files themselves. There is only one other occurrence of "encoding" remotely relevant to the present discussion. 5.1 last para, dealing with special characters and escape sequences: Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. There is nothing in the subsequent \DDD description to indicate that the decimal number represents an ASCII code point, which it clearly must if labels are ASCII encoded. The other occurrences of "encoding" are in section 8, and deal with mailbox addresses and related matters of no interest here. The proposition that RFC1035 mandates ASCII "presentation format" is demonstrably false. >8 > ... An application could choose to encode the presentation format using a > different encoding, but that's outside the scope of the protocol. Application programs do not "choose the encoding"; that "choice" is inflicted upon them by the I/O system provided by the platform on which they run. If the platform uses EBCDIC, then "presentation format" is EBCDIC encoded, constrained (in this instance) to use the same printable character repertoire as on an ASCII platform. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dns-wireformat-http-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : An Proxy Use Case of DNS over HTTPS Authors : Linjian Song Paul Vixie Shane Kerr Filename: draft-ietf-dnsop-dns-wireformat-http-03.txt Pages : 6 Date: 2018-07-02 Abstract: This memo introduces a DNS proxy use case to tunnel DNS query and response using DNS over HTTPs (DOH) protocol, a newly proposed DNS transport. The proxy use case is useful as a incremental adoption tool when DOH is not widely available in old-transport client and server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-03 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-wireformat-http-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-wireformat-http-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 2nd Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
Firstly, thank you! (for keeping the WG informed, I met with Joe in Panama and thanked him then too). I generally like to update at least the GitHub version during WGLC so that people can better see the current state, but this time travel and such got in the way. I have integrated / addressed most of these, and posted a new version. Because I only got around to addressing them around 2 hours before the draft cutoff I haven't checked with my co-authors, nor created separate GitHub issues for them. Thanks again! W On Fri, Jun 22, 2018 at 12:19 PM Joe Abley wrote: > Hi Benno, > > On 22 Jun 2018, at 11:04, Benno Overeinder wrote: > > > This starts a *one* week Working Group Last Call process, and ends on: > > 23:59 29 June 2018. > > Which timezone? Seems odd to specify a timestamp with minute-accuracy > without specifying the hour :-) > > === General > > I have read draft-ietf-dnsop-kskroll-sentinel-14. In my opinion it is > ready to proceed. > > I have some small nits that someone might care about, and if they don't > care about them I will not be offended, even if they roll their eyes. I > think at least some of them make the document clearer, though, and perhaps > aren't very contentious. None of them take issue with the specification > itself, just its description. > > === Section 1, Introduction > > DNS, RR and KSK are used as acronyms without being expanded on first use. > I chose not to expand DNS (it is sufficiently well known, and doing so made it unreadable). I expanded RR and KSK. Thank you! > > The first paragraph refers to "a formula similar to a ones-complement > checksum" in reference to Appendix B of RFC 4034. In fact that document > specifies two algorithms for computing key tags, one for the old RSA/MD5 > algorithm 1 and one for all others. "Ones-complement" is properly "ones' > complement". This document uses "formula" to describe what 4034 describes > as an algorithm. DNSKEY RRs don't validate signatures. These are > ridiculously pedantic points (for the sake of brevity I will avoid > mentioning that again, but you can assume it if it's not obvious). > > OLD: > > The Key Tag is a 16-bit value computed from the RDATA portion of a DNSKEY > RR using a formula found in "Key Tag Calculation" (Appendix B of "Resource > Records for the DNS Security Extensions" [RFC 4034]), a formula similar to > a ones-complement checksum. RRSIG RRs contain a Key Tag field whose value > is equal to the Key Tag of the DNSKEY RR that validates the signature. > > NEW: > > The Key Tag is a 16-bit value computed from the RDATA of a DNSKEY RR as > described in Appendix B of RFC 4034. RRSIG RRs contain a Key Tag field > whose value is equal to the Key Tag of the DNSKEY RR that was used to > generate the corresponding signature. > > Thank you, and thank you also for providing OLD and NEW. Done. > A little further in the same section: I don't think mechanisms meet > use-cases, but rather satisfy their requirements. I think normative > language for the configuration commentary could make the sentiment clearer. > I think actually that it would be better for the advice about configuration > defaults to be moved to section 2, since an implementer might reasonably > skip over the introduction and miss it. > > OLD: > > The mechanism described in this document meets both of these use cases. > This new mechanism is OPTIONAL to implement and use, although for reasons > of supporting broad-based measurement techniques, it is strongly preferred > that configurations of DNSSEC-validating resolvers enabled this mechanism > by default, allowing for local configuration directives to disable this > mechanism if desired. > > NEW: > > The mechanism described in this document satisfy the requirements of both > these use-cases. This mechanism is OPTIONAL to implement and use. If > implemented, this mechanism SHOULD be enabled by default to facilitate > Internet-wide measurement. Configuration options MAY be provided to disable > the mechanism for reasons of local policy. > > Thank you, and for providing NEW text (thanks implicit in all follow-ons too!). This adds a SHOULD -- I'm assuming that the WG is OK with it. DONE. > In the final paragraph, I think speculating on the utility of this > mechanism vs. RFC 8145 is unnecessary. Note that I don't disagree with the > sentiment, I just don't think it's relevant or useful as commentary. > > OLD: > > Note that the sentinel mechanism described here measures a very different > (and likely more useful) metric than [RFC8145]. > > NEW: > > Note that the measurements facilitated by the mechanism described in this > document are different from those of [RFC8145]. > Fair enough. DONE. > > === Section 2, Sentinel Mechanism in Resolvers > > I wonder whether it's worth being explicit about labels in QNAMEs that > almost match those specified, but not quite. Out of general enthusiasm for > being generous about what you accept, for example, it seems possible that > some
[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-15.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : A Root Key Trust Anchor Sentinel for DNSSEC Authors : Geoff Huston Joao Silva Damas Warren Kumari Filename: draft-ietf-dnsop-kskroll-sentinel-15.txt Pages : 21 Date: 2018-07-02 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. [ This document is being collaborated on in Github at: https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. RFC Editor, please remove text in square brackets before publication. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-15 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Extended DNS Errors Authors : Warren Kumari Evan Hunt Roy Arends Wes Hardaker David C Lawrence Filename: draft-ietf-dnsop-extended-error-01.txt Pages : 11 Date: 2018-07-02 Abstract: This document defines an extensible method to return additional information about the cause of DNS errors. The primary use case is to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures. [ Open question: The document currently defines a registry for errors. It has also been suggested that the option also carry human readable (text) messages, to allow the server admin to provide additional debugging information (e.g: "example.com pointed their NS at us. No idea why...", "We don't provide recursive DNS to 192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and DNS? We do DNS right..." (!). Please let us know if you think text is needed, or if a 16bit FCFS registry is expressive enough. ] [ Open question: This document discusses extended *errors*, but it has been suggested that this could be used to also annotate *non- error* messages. The authors do not think that this is a good idea, but could be persuaded otherwise. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-session-signal-11.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Stateful Operations Authors : Ray Bellis Stuart Cheshire John Dickinson Sara Dickinson Ted Lemon Tom Pusateri Filename: draft-ietf-dnsop-session-signal-11.txt Pages : 53 Date: 2018-07-02 Abstract: This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions, using type-length-value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header opcode and result code which has different message semantics. This document updates RFC 7766 by redefining a session, providing new guidance on connection re-use, and providing a new mechanism for handling session idle timeouts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-11 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-woodworth-bulk-rr-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : BULK DNS Resource Records Authors : John Woodworth Dean Ballew Shashwath Bindinganaveli Raghavan David C Lawrence Filename: draft-woodworth-bulk-rr-08.txt Pages : 16 Date: 2018-07-02 Abstract: The BULK DNS resource record type defines a method of pattern-based creation of DNS resource records based on numeric substrings of query names. The intent of BULK is to simplify generic assignments in a memory-efficient way that can be easily shared between the primary and secondary nameservers for a zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-woodworth-bulk-rr-08 https://datatracker.ietf.org/doc/html/draft-woodworth-bulk-rr-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-woodworth-bulk-rr-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Creating a query/record for A and AAAA
On Mon, 2 Jul 2018, Jared Mauch wrote: As a longtime ANY (ab)user, I welcome an approach where we get + A at the same time. This can be done by just returning the additional but it really depends on if the clients or stubs will use it. If you are trusting an unsigned A record in the answer section, you might as well trust the unsigned record in the additional section too. I think minimum responses should still always just include this. Paul (although doing this only for DNSSEC would be a good motivator :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-06.txt
This is conceptually similar to [accompanying-questions], but limits all questions to share a QNAME. The result is a more concise payload and simpler processing logic at the expense of an ability to request e.g. (www.example.com, A) and (_443._tcp.www.example.com, TLSA) in one query. I can imagine many scenarios where such queries would be valuable, though, and am suspicious about the tradeoff (which essentially supports only A+ queries) being worthwhile. [accompanying-questions] had some [issues] of its own to work out, but seemed to fall at approximately the right level of flexibility for allowing clients to query for more than one tuple. [accompanying-questions]: https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ [issues]: https://www.ietf.org/mail-archive/web/dnsop/current/msg21085.html On 07/02/2018 08:51 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Multiple QTYPEs Author : Ray Bellis Filename: draft-bellis-dnsext-multi-qtypes-06.txt Pages : 7 Date: 2018-07-02 Abstract: This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM&s=nAF1psaBl4BrcSH12DDD8-h4jVVriftlNvhtAmFlY5Q&e= There are also htmlized versions available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes-2D06&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM&s=D1oTk_bgVu4lj3OjjuiXoxOIuBBbIL0KO6kbHZ9_hRM&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes-2D06&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM&s=8WzllvYxQajep8eqJqq3yV2J_tRoOKYnow5bwzceXx8&e= A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes-2D06&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM&s=J471bGTuh5C7VV8996erxtZkgU-KZ5fbUOgkqqEtR-I&e= Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM&s=kfPI_hiW8R7kJUNYC9wrFWmPV07xPNgiZcm7jtOdhjA&e= ___ DNSOP mailing list DNSOP@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM&s=aFTa0u2T8MtsiQHha6UQaRdLL3FoifHiU9sY-XorioQ&e= ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Creating a query/record for A and AAAA
> On Jun 29, 2018, at 12:38 PM, Paul Vixie wrote: > > > > Michael Sheldon wrote: >> Breaking this out of the ANAME discussion, since it has wider use. >> >> I've been thinking on this one. If I was to create a record, I'd set >> aside a byte or two at the beginning to denote family, but I'm just >> paranoid and OCD that way. > > that seems like the long way around. > > for QTYPE=A, add as a desired additional data type. > > for QTYPE=, add A as a desired additional data type. > > advantages: > > no fork-lifts. incremental. opportunistic. no protocol changes. start today. > > any server which does it will give better time-to-first-ad benchmarks, and > will therefore outcompete any server who doesn't do it in all bakeoffs. > I guess this depends on how the vendors implement the various minimal response bits. I’ve turned this on because in ye olden days (I think it was the 2nd half of the 90s) you could poison a cache by dumping in additional data, sometimes even out of the zone additional and cause this trouble. This is also documented as a performance gain, either due to less time packing the response or other wins. As a longtime ANY (ab)user, I welcome an approach where we get + A at the same time. This can be done by just returning the additional but it really depends on if the clients or stubs will use it. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Multiple QTYPEs Author : Ray Bellis Filename: draft-bellis-dnsext-multi-qtypes-06.txt Pages : 7 Date: 2018-07-02 Abstract: This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-06 https://datatracker.ietf.org/doc/html/draft-bellis-dnsext-multi-qtypes-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsext-multi-qtypes-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Creating a query/record for A and AAAA
Hi, > On 2 Jul 2018, at 11:53, Tony Finch wrote: > > Paul Vixie wrote: >> >> for QTYPE=A, add as a desired additional data type. >> >> for QTYPE=, add A as a desired additional data type. > > How does the server signal to a client that made an A query that there > are no records so the client does not need to make a followup > query? My answer: use DNSSEC :-) > > What are the incentives to implement this? The current state of the art is > happy eyeballs version 2, which specifies concurrent and A queries; > the client has already made both queries before it finds out it only > needed to make one. I'm not sure how a client could know in advance that > it only needs to make one query. This really isn’t about incentives, but not making the situation worse. A single query without signalling (opportunistic) and without state will double the latency compared to dual A + query fired at the same time. > I think there would be some benefit to this between auth and recursive, > provided the recursive server eagerly validates additional records and > promotes them to the authoritative answer level of RFC 2181 trust. So, instead of adding additional complexity of validating and storing the unsolicited information in additional section, the “prefetch” code in resolvers could be enhanced to pre-fill the cache with additional records when specific RTYPE is requested… Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Creating a query/record for A and AAAA
Paul Vixie wrote: > > for QTYPE=A, add as a desired additional data type. > > for QTYPE=, add A as a desired additional data type. How does the server signal to a client that made an A query that there are no records so the client does not need to make a followup query? My answer: use DNSSEC :-) What are the incentives to implement this? The current state of the art is happy eyeballs version 2, which specifies concurrent and A queries; the client has already made both queries before it finds out it only needed to make one. I'm not sure how a client could know in advance that it only needs to make one query. I think there would be some benefit to this between auth and recursive, provided the recursive server eagerly validates additional records and promotes them to the authoritative answer level of RFC 2181 trust. Tony. -- f.anthony.n.finchhttp://dotat.at/ partnership and community in all areas of life ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Thanks Paul! I'm very happy with all the proposed formulation changes (your commit 0fqxn1k41). --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
