Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback
> From: Paul Hoffman >> If resolvers are encouraged to use NSEC records to synthesize NXDOMAIN >> responses, would there still be any point to this draft? > > Yes. No one has written up a document on using NSEC records to synthesize > NXDOMAIN for the root, and if they do, there will certainly be operational > considerations for that that are different than the operational > considerations for this draft. I'm not saying one would be better than the > other, but I suspect that the operational description of this draft would be > easier for an operator to understand. I wroite "Aggressive use of NSEC/NSEC3 resource records may decrease queries to Root DNS servers." in draft-fujiwara-dnsop-nsec-aggressiveuse-00 as a side effect. Is it related to root-loopback document? # I will update the draft soon. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-edns-client-subnet-01
Since draft-ietf-dnsop-edns-client-subnet-01 theoretically reverted the changes made in -00 from draft-vandergaast-edns-client-subnet then why is the last sentence here with a SHOULD. MUST be omitted would be correct to match draft-vandergaast-edns-client-subnet and the IANA assignment of the option code. o ADDRESS, variable number of octets, contains either an IPv4 or IPv6 address, depending on FAMILY, truncated to the number of bits indicated by the SOURCE PREFIX-LENGTH field, with bits set to 0 to pad to the end of the last octet needed. Trailing all-zero octets SHOULD be omitted. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 2181 - reconsiderations
> On Jun 8, 2015, at 3:11 PM, manning wrote: > > What do you think? Is there a reason to not do this? DNS implementation details are much cleaner than others (e.g.: BGP) in finding the root documents and all the additive parts. In other words, I support pushing these out. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC 2181 - reconsiderations
Morning y’all.RFC 2181 is a “grab bag” of eight independent items that, 17 years ago, were not considered “large” enough to warrant dedicated RFCs. Quoting from the abstract of the RFC: "Eight separate issues are considered: + IP packet header address usage from multi-homed servers, + TTLs in sets of records with the same name, class, and type, + correct handling of zone cuts, + three minor issues concerning SOA records and their use, + the precise definition of the Time to Live (TTL) + Use of the TC (truncated) header bit + the issue of what is an authoritative, or canonical, name, + and the issue of what makes a valid DNS label. The first six of these are areas where the correct behaviour has been somewhat unclear, we seek to rectify that. The other two are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specifications.” It has become unwieldy to try and work on any specific item here without an effect on this base document. There are eight drafts (currently individual submissions), one for each of these eight issues. I’ve read the drafts and they have extracted the RFC2181 text for each specific issue, verbatim and placed each into a dedicated document. This suggests that as a strictly process issue, that the WG could choose to adopt and fast track these eight IDs to RFC status. That way work could proceed independently on each of the issues and RFC 2181 could be moved to Historic status. What do you think? Is there a reason to not do this? manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarification on EDNS 6891
On 03/06/2015 17:22, Joe Abley wrote: > I think there's a baked-in expectation that OPT pseudo-RR is included in > every DNS message, not on every connection (where the transport is > connection-oriented). Joe, Part of the reason this came up is this text in draft-ietf-edns-tcp-keepalive: "DNS clients MAY include the edns-tcp-keepalive option in the first query sent to a server using TCP transport to signal their desire that that specific TCP session be used for multiple DNS transactions." > While the conventional case of resolver-talks-to-authority makes this > seem like a highly pedantic observation, we can never be sure of what is > happening behind the curtain; ALGs that bridge between transports > (providing a UDP interface on one side but managing a TCP connection > pool on the other, for example) exist, for example. Yes, an ALG such as this was the most compelling (albeit hypothetical) reason that I could think of for not making this assumption, but then EDNS is *supposed* to be hop-by-hop. kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
