Re: [DNSOP] [Ext] Reserved field in draft-wessels-dns-zone-digest-04.txt
Paul Hoffman writes:
> From the earlier list discussion and your presentation at DNS-OARC,
> processing dynamic zones is hard, and you might make different choices
> based on different amounts of dynamicness (dynamicity?). This should
> cause developers concern about implementing ZONEMD now because there
> will be an expectation that they will have to implement the changes in
> the future.
I also look at it in terms of implementation complexity and where in the
code base decisions are made. EG, if you have different RRTYPEs for
signaling things, then the logic is straight forward:
if (rrtype == ZONEMD) {
do_ZONEMD_stuff();
} else if (rrtype == ZONEMDMERKLE) {
do_fancy_new_hashtree_stuff();
} ...
On the other hand, with a reserved field we end up here:
if (rrtype == ZONEMD) {
do_ZONEMD_stuff();
} ...
do_ZONEMD_stuff() {
if (reserved_field != 0) {
do_fancy_new_hashtree_stuff();
} else {
do_ZONEMD_stuff();
}
}
Now, if do_ZONEMD_stuff() and do_fancy_new_hashtree_stuff() are likely
to be sufficiently different in implementation (and I suspect they will
be), then the first code above with two RRTYPEs is likely to be
cleaner. The only advantage gained in the second type is if you can put
the brunt of the code for both do_fancy_new_hashtree_stuff() and
do_ZONEMD_stuff() pretty much inline because there is sufficient
overlap.
It's hard to predict what the best route is advance without knowing now
how much the resulting double implementation will overlap.
Personally (authorship hat off and thus collector of consensus hat off),
I think we should use a second RRTYPE for the future as it's easier to
make implementations more module and remove earlier implementations when
that specification is no longer used because hashtrees are so cool that
nothing else is ever needed.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt
On Sat, Nov 03, 2018 at 03:12:28PM +0700, Mukund Sivaraman wrote: > The D flag seems unnecessary. Just the presence of the EDNS option in > query from the client should serve to indicate to a server that the > client explicitly does not want stale answers. I withdraw this comment. It appears that the client can also find out whether an option is stale by sending the option. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt
I've reviewed older revisions of the draft and still +1 the idea. It would be useful practically in today's world where temporary DDoS attacks inundate authorities. Review comments on this revision of the draft: >This document proposes that the definition of the TTL be explicitly >expanded to allow for expired data to be used in the exceptional >circumstance that a recursive resolver is unable to refresh the >information. It is predicated on the observation that authoritative >server unavailability can cause outages even when the underlying data >those servers would return is typically unchanged. While reading this, I wonder whether the last sentence was meant to be written as: "It is predicated on the observation that zone data returned by authoritative nameservers during a resolver refresh would typically be unchanged." >We describe a method below for this use of stale data, balancing the >competing needs of resiliency and freshness. While this is intended >to be immediately useful to the installed base of DNS software, we >also propose an [RFC6891] EDNS option for enhanced signalling around >the use of stale data by implementations that understand it. > 2. Notes to readers >[ RFC Editor, please remove this section before publication! >Readers: This is conversational text to describe what we've done, and >will be removed, please don't bother sending editorial nits. :-) ] >Due to circumstances, the authors of this document got sidetracked, >and we lost focus. We are now reviving it, and are trying to address >and incorporate comments. There has also been more deployment and >implementation recently, and so this document is now more describing >what is known to work instead of simply proposing a concept. >Open questions: >o The EDNS option that we propose for debugging is relatively full- > featured to identify which RRsets are stale. It could be > simplified to just indicate that an answer is stale, or even > removed entirely in favour of an Extended Error result that > indicates staleness. >o What TTL value to recommend be set in stale answers returned by > recursive resolvers. > 3. Terminology >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >"OPTIONAL" in this document are to be interpreted as described in >[RFC2119] when, and only when, they appear in all capitals, as shown >here. RFC 8174 has updated RFC 2119. Please check this draft vs. what's in RFC 8174 and update the above paragraph. >For a comprehensive treatment of DNS terms, please see [RFC7719]. > 4. Background >There are a number of reasons why an authoritative server may become >unreachable, including Denial of Service (DoS) attacks, network >issues, and so on. If the recursive server is unable to contact the >authoritative servers for a name but still has relevant data that has s/for a name/for a query/ >aged past its TTL, that information can still be useful for >generating an answer under the metaphorical assumption that, "stale Remove this comma -^^^ >bread is better than no bread." >[RFC1035] Section 3.2.1 says that the TTL "specifies the time >interval that the resource record may be cached before the source of >the information should again be consulted", and Section 4.1.3 further >says the TTL, "specifies the time interval (in seconds) that the >resource record may be cached before it should be discarded." >A natural English interpretation of these remarks would seem to be >clear enough that records past their TTL expiration must not be used, >However, [RFC1035] predates the more rigorous terminology of Either make comma after "used" a full-stop, or lowercase the H in "However". >[RFC2119] which softened the interpretation of "may" and "should". >[RFC2181] aimed to provide "the precise definition of the Time to >Live" but in Section 8 was mostly concerned with the numeric range of s/ but in Section 8/, but in Section 8,/ >values and the possibility that very large values should be capped. >(It also has the curious suggestion that a value in the range >2147483648 to 4294967295 should be treated as zero.) It closes that >section by noting, "The TTL specifies a maximum time to live, not a >mandatory time to live." This is again not [RFC2119]-normative >language, but does convey the natural language connotation that data >becomes unusable past TTL expiry. >Several major recursive resolver operators currently use stale data >for answers in some way, including Akamai (via both Nomimum and >Xerocole), Knot, OpenDNS, and Unbound. You can now add BIND to this list. :) >Apple can also use stale data as part of the
Re: [DNSOP] KSK rollover choices
Joe Abley writes: > I think the wider problem space might be better described as trust > anchor publication and retrieval. Couldn't have said it better myself (more specifically, I didn't). The problem space is much bigger than 5011, and 5011 is but one tool to solve a piece of the whole space. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fundamental ANAME problems
Brian Dickson 于2018年11月2日周五 上午9:38写道： > On Thu, Nov 1, 2018 at 5:14 PM John Levine wrote: > >> I can't help but note that people all over the Internet do various >> flavors of ANAME now, and the DNS hasn't fallen over. Let us not make >> the same mistake we did with NAT, and pretend that since we can't find >> an elegant way to do it, we can put our fingers in our ears and it >> will go away. >> >> > Did you not read my full message? > I didn't say don't do that, I said let's do it in an elegant way. > Then I provided a few examples of how to do that. > > What is being done now is not ANAME by any stretch; it is > vertically-integrated apex CNAME flattening. > Yes, there are several providers doing it. > Their customers are locked in to a single provider, precisely because of > that vertical integration. > None of their customers can have multi-vendor redundancy with feature > parity. > While not a prime motivation for ANAME or its alternatives, it is > certainly (or should be) one of its goals. > > The fact that each existing vendor's solution is, and requires, vertical > integration, means each is fundamentally a closed system, with no interop > possible. > > What ANAME, and the other suggested things, are doing is figuring out how > to do interoperable stuff that allows something kind of like a CNAME, to > co-exist at an apex. > > Can you point me to a non-closed, non-vertically-integrated ANAME-like > thing that offers interoperable multi-vendor support? > > I think you are confusing "dynamic update of A based on > meta-data-configured FQDN" with actual ANAME. > > So, DNS not having fallen over yet, has nothing at all to do with ANAME. > > >> In article < >> cah1icirxysyb3sao8f1jy-q4melmqapsfo-7x5iddufdt_u...@mail.gmail.com> you >> write: >> >The requirement on update rate, is imposed externally by whichever entity >> >operates the ANAME target. In other words, this is not under the direct >> >control of the zone operator, and is potentially a potentially (and very >> >likely) UNBOUNDED operational impact/cost. >> >> "Something very bad will happen if I do that." "OK, so don't do >> that." My aname-ish code has a maximum update rate, and I expect >> everyone else's does too. Yeah, the ANAMEs won't be in sync with >> the hostile remote server, but I can't get too upset about that. >> > > How many zones do you operate this way? > What is the maximum update rate? > Are those zones you operate on behalf of paying customers? > If those were paying customers, and the records got out of sync, don't you > think the customers would get upset? > > That's the primary point; when non-toy situations with paying customers > are considered, it isn't up to you to decide what the update rate is, and > you don't have the luxury of not caring. > > It isn't whether it works for you; it's whether it works for EVERYBODY. > If it doesn't, then we need to work harder on the problem. > > >> >> >Third, there is an issue with the impact to anycast operation of zones >> with >> >ANAMEs, with respect to differentiated answers, based on topological >> >locations of anycast instances. >> >> How is this different from CNAMEs via to 8.8.8.8 and other anycast >> caches? The cache has no relation to the location of the client unless >> you use one of the client location hint hacks. >> > > Because authority servers for the same zone, when not doing stupid DNS > tricks, are in sync. > This is by design, and is the expectation of clients, resolvers, and > registrants. > > Anycast caches do not have any expectation or requirement to be sync'd, > and in particular, due to stupid DNS tricks, are typically topologically > sync'd to regional answers. > > Anycast caches with smaller footprint or odd customer bases, might do > those hacks, but even without them, there will be significant differences > in the contents of those caches, in different locations. > > The problem is the ANAME *target* -- that will typically also be > topologically diverse, e.g. answers supplied will involve stupid DNS tricks. > > You can't have your ANAME use only a single view and push that SAME answer > to all anycast nodes. > Doing so would break the client->resolver->(anycast auth)->ANAME-target > model of diversified answers. > If client/resolver are supposed to hit ANAME-targets (which are themselves > anycast, but which do stupid DNS tricks to give different answers) and get > DIFFERENT answers, then having only one instance of the ANAME-target > returned by the anycast auth (regardless of location) will be an > "#EpicFail". > > Example: > >- client in Los Angeles -> resolver somewhere in California -> ??? -> >AWS obfuscated-name -> California IP address (based on resolver IP, or >maybe client-subnet) >- client in Boston -> resolver somewhere in New England -> ??? -> AWS >obfuscated-name -> New York IP address (based on resolver IP, or maybe >client-subnet) >- If ??? is an ANAME, which does a tracking query FROM ONE LOCATION, >
Re: [DNSOP] Minimum viable ANAME
On 21/09/2018 20:12, Dan York wrote: I do think this is a path we need to go. We need *something* like CNAME at the apex. Either CNAME itself or something that works in the same way but might have a different name. I agree, and earlier today (well, yesterday, now) I wrote it up: A new version of I-D, draft-bellis-dnsop-http-record-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. Name: draft-bellis-dnsop-http-record Revision: 00 Title: A DNS Resource Record for HTTP Document date: 2018-11-04 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsop-http-record-00.txt Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-http-record/ Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-http-record-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-http-record Abstract: This document specifies an "HTTP" resource record type for the DNS to facilitate the lookup of the server hostname of HTTP(s) URIs. It is intended to replace the use of CNAME records for this purpose, and in the process provides a solution for the inability of the DNS to allow a CNAME to be placed at the apex of a domain name. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Review of draft-ietf-dnsop-7706bis-01.txt
Review comments follow: > Decreasing Access Time to Root Servers by Running One On The Same Server > draft-ietf-dnsop-7706bis-01 > Abstract >Some DNS recursive resolvers have longer-than-desired round-trip >times to the closest DNS root server. Some DNS recursive resolver >operators want to prevent snooping of requests sent to DNS root >servers by third parties. It took a while for me to follow this last sentence. It would be better to rewrite it as "Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers." For a long time I was reading the intention as "... requests sent to DNS root servers by [the resolver's clients]." >Such resolvers can greatly decrease the >round-trip time and prevent observation of requests by running a copy >of the full root zone on the same server, such as on a loopback >address. I'd substitute "running" with hosting or serving, and s/on the same server/locally/ >This document shows how to start and maintain such a copy >of the root zone that does not pose a threat to other users of the >DNS, at the cost of adding some operational fragility for the >operator. s/pose a threat to/cause problems for/ >This draft will update RFC 7706. See Section 1.1 for a list of >topics that will be added in the update. >[ Ed note: Text inside square brackets ([]) is additional background >information, answers to freqently asked questions, general musings, >etc. They will be removed before publication.] >[ This document is being collaborated on in Github at: >https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent >version of the document, open issues, and so on should all be >available there. The authors gratefully accept pull requests. ] > Status of This Memo >This Internet-Draft is submitted in full conformance with the >provisions of BCP 78 and BCP 79. >Internet-Drafts are working documents of the Internet Engineering >Task Force (IETF). Note that other groups may also distribute >working documents as Internet-Drafts. The list of current Internet- >Drafts is at https://datatracker.ietf.org/drafts/current/. >Internet-Drafts are draft documents valid for a maximum of six months >and may be updated, replaced, or obsoleted by other documents at any >time. It is inappropriate to use Internet-Drafts as reference >material or to cite them other than as "work in progress." >This Internet-Draft will expire on April 25, 2019. > Copyright Notice >Copyright (c) 2018 IETF Trust and the persons identified as the >document authors. All rights reserved. >This document is subject to BCP 78 and the IETF Trust's Legal >Provisions Relating to IETF Documents >(https://trustee.ietf.org/license-info) in effect on the date of >publication of this document. Please review these documents >carefully, as they describe your rights and restrictions with respect >to this document. Code Components extracted from this document must >include Simplified BSD License text as described in Section 4.e of >the Trust Legal Provisions and are provided without warranty as >described in the Simplified BSD License. > Table of Contents >1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 > 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 >2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 >3. Operation of the Root Zone on the Local Server . . . . . . . 5 >4. Using the Root Zone Server on the Same Host . . . . . . . . . 7 >5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 >6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 > 6.2. Informative References . . . . . . . . . . . . . . . . . 8 >Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 >Appendix B. Example Configurations of Common Implementations . . 9 > B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9 > B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 > B.3. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10 > B.4. Example Configuration: Microsoft Windows Server 2012 . . 11 >Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 >Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 > 1. Introduction >DNS recursive resolvers have to provide answers to all queries from >their customers, even those for domain names that do not exist. For >each queried name that has a top-level domain (TLD) that is not in s/that has a/that is within a/ >the
Re: [DNSOP] Fundamental ANAME problems
On Nov 3, 2018, at 03:20, Bob Harold wrote: > My preference would be a *NAME record that specifies which record types it > applies to. So one could delegate A and at apex to a web provider, MX > to a mail provider, etc. That would also be valuable at non-apex names. But > I am happy to support ANAME as part of the solution. I don't understand this suggestion. Some use-cases (or even hypothetical examples) might help. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it more DNS-aligned (e.g. the name as a separate field in the record) not help here? It comes from the HTTP world and is aligned with the existing AltSvc feature and thus is useful in other ways (such as perhaps solving the DNS deployabilty issues for encrypted SNI): https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02 - Erik On Sun, Sep 23, 2018, 10:41 AM Ray Bellis On 21/09/2018 19:11, JW wrote: > > > I also feel from this discussion, we are all roughly on the same page. > > We want SRV as the long term solution ... > > except that we heard at the side meeting in Montreal (albeit from > browser people rather than content people) that they *don't* want SRV, > because it has fields that are not compatible with the web security model. > > I still want to define a new RR that does have mutually agreed semantics > that's specifically for use by HTTP(s), but so far no takers. > > Ray > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-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 : DNS Scoped Data Through "Underscore" Naming of Attribute Leaves Author : Dave Crocker Filename: draft-ietf-dnsop-attrleaf-15.txt Pages : 14 Date: 2018-11-03 Abstract: Formally, any DNS resource record may occur under any domain name. However some services use an operational convention for defining specific interpretations of an RRset, by locating the records in a DNS branch, under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with an _underscore. The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain, above the underscored branch. This specification explores the nature of this DNS usage and defines the "DNS Global Underscore Scoped Entry Registry" with IANA. The purpose of the Underscore registry is to avoid collisions resulting from the use of the same underscore-based name, for different services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-15 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-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
Re: [DNSOP] Minimum viable ANAME
Ray Bellis wrote: On 21/09/2018 20:12, Dan York wrote: I do think this is a path we need to go. We need *something* like CNAME at the apex. Either CNAME itself or something that works in the same way but might have a different name. I agree, and earlier today (well, yesterday, now) I wrote it up: A new version of I-D, draft-bellis-dnsop-http-record-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. ... the arguments against SRV in that document are unsupported and wrong. While there have been previous attempts to promote the use of the SRV record instead of CNAME records, there have been concerns raised about the performance impact of the additional DNS lookup an SRV record would typically require. SRV responses include additional data. To achieve equivalent end-user performance as existing CNAME-based solutions, this document permits recursive resolvers to pre-emptively look up the target of an HTTP Record and return the corresponding records to the client. While this feature is not mandatory it is hoped that support would over time become near ubiquitous. i think that makes HTTP as fast in terms of round trips as SRV is. Also, the presence of the Port field in an SRV record is incompatible with the "Same Origin" security policy enforced by web browsers and in practise the load-balancing / fallback capabilities of the SRV record are not widely used either, ... so use "0" for the port number, and don't include more than one SRV RR. ... and non-DNS based solutions for this are already widely deployed for HTTP traffic. so just keep using non-DNS solutions. there's no benefit to accompany the cost of this proposal compared to re-use of existing code points which are already broadly implemented. the HTTP folks are obviously not interested in round trips, anyway: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37345 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ; COOKIE: 5a8f3fa2fa447f4c (echoed) ;; QUESTION SECTION: ;www.microsoft.com. IN A ;; ANSWER SECTION: www.microsoft.com. 3600IN CNAME www.microsoft.com-c-3.edgekey.net. ;; Query time: 23 msec ;; SERVER: 2620:0:30::53#53(2620:0:30::53) ;; WHEN: Sat Nov 03 23:52:17 UTC 2018 ;; MSG SIZE rcvd: 105 -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-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 Attrleaf Changes: Fixing Specifications with Underscored Node Name Use Author : Dave Crocker Filename: draft-ietf-dnsop-attrleaf-fix-06.txt Pages : 14 Date: 2018-11-03 Abstract: Original uses of an underscore character as a domain node name prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name- creation activities, all drawing from the same namespace. A registry now has been defined. However the existing specifications that use underscore naming need to be modified, to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-06 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-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] Fundamental ANAME problems
Subject: Re: [DNSOP] Fundamental ANAME problems Date: Sat, Nov 03, 2018 at 12:04:18PM -0700 Quoting Joe Abley (jab...@hopcount.ca): > On Nov 3, 2018, at 03:20, Bob Harold wrote: > > > My preference would be a *NAME record that specifies which record types it > > applies to. So one could delegate A and at apex to a web provider, MX > > to a mail provider, etc. That would also be valuable at non-apex names. > > But I am happy to support ANAME as part of the solution. > > I don't understand this suggestion. > > Some use-cases (or even hypothetical examples) might help. example.org. IN SOA foo bar 2018102802 300 3600 360 300 example.org. IN NS primary.se. example.org. IN NS secondary.se. example.org. IN MX 10 some.host.gmail.com _http._tcp.example.org. IN URI 10 20 "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/; example.org. IN TXT "v=spf0x41 not valid. because SPF records belong in RRtype 99." example.org. IN AFSDB 1 db0.example.org. example.org. IN AFSDB 1 db1.example.org. example.org. IN AFSDB 1 db2.example.org. example.org. IN SPF "v=spf1 +all" We already have this. We need not build a new mechanism. /Måns, sounding like a broken record. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR+46 705 989668 Is this an out-take from the "BRADY BUNCH"? signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
On 04/11/2018 06:53, Paul Vixie wrote: the arguments against SRV in that document are unsupported and wrong. They are something of a straw man, yes. We did hear unequivocally at the side meeting in Montreal that SRV is not acceptable to the HTTP folks, though, for the broad reasons mentioned in my draft. SRV responses include additional data. AFAIK, BIND does not currently do this. That said, MarkA has a patch that supports it, so we do know it's possible. i think that makes HTTP as fast in terms of round trips as SRV is. The intent is to make it as fast as CNAME, and faster than SRV currently is. so use "0" for the port number, and don't include more than one SRV RR. If the record supports it, people will want to use it, and complain when they can't. so just keep using non-DNS solutions. No argument from me, I've always strongly believed that if load-balancing and/or failover are the question then DNS is not the answer. there's no benefit to accompany the cost of this proposal compared to re-use of existing code points which are already broadly implemented. There appear to be political benefits, though. Code points are cheap these days, and the point of this document is to try to introduce something where the DNS folk and the HTTP folks can "meet in the middle" with a mutually acceptable solution. the HTTP folks are obviously not interested in round trips, anyway: Sometimes the content folk appear less interested in this than the UI folk. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Reserved field in draft-wessels-dns-zone-digest-04.txt
> On Nov 3, 2018, at 1:33 PM, Wes Hardaker wrote:
>
> Paul Hoffman writes:
>
>> From the earlier list discussion and your presentation at DNS-OARC,
>> processing dynamic zones is hard, and you might make different choices
>> based on different amounts of dynamicness (dynamicity?). This should
>> cause developers concern about implementing ZONEMD now because there
>> will be an expectation that they will have to implement the changes in
>> the future.
>
> I also look at it in terms of implementation complexity and where in the
> code base decisions are made. EG, if you have different RRTYPEs for
> signaling things, then the logic is straight forward:
>
>if (rrtype == ZONEMD) {
> do_ZONEMD_stuff();
>} else if (rrtype == ZONEMDMERKLE) {
> do_fancy_new_hashtree_stuff();
>} ...
>
> On the other hand, with a reserved field we end up here:
>
>if (rrtype == ZONEMD) {
> do_ZONEMD_stuff();
>} ...
>
>
>do_ZONEMD_stuff() {
>if (reserved_field != 0) {
>do_fancy_new_hashtree_stuff();
>} else {
>do_ZONEMD_stuff();
>}
>}
>
> Now, if do_ZONEMD_stuff() and do_fancy_new_hashtree_stuff() are likely
> to be sufficiently different in implementation (and I suspect they will
> be), then the first code above with two RRTYPEs is likely to be
> cleaner. The only advantage gained in the second type is if you can put
> the brunt of the code for both do_fancy_new_hashtree_stuff() and
> do_ZONEMD_stuff() pretty much inline because there is sufficient
> overlap.
>
> It's hard to predict what the best route is advance without knowing now
> how much the resulting double implementation will overlap.
So there is an implementation of ZONEMD, and even an implementation of "fancy
hashtree stuff". You can find it at
https://github.com/verisign/ldns-zone-digest
One of the reasons I think the variable-depth hash tree is attractive is
because when depth = 0 then it simplifies exactly to the case as though there
is no fancy hashtree.
In my proof-of-concept implementation, most of the added complexity from fancy
hashtree stuff comes in the form of how the zone data is stored. For example:
#if !ZONEMD_INCREMENTAL
ldns_rr_list *the_rrlist = 0;
#endif
#if ZONEMD_INCREMENTAL
typedef struct _zonemd_tree {
unsigned int depth;
unsigned int branch;// only for debugging?
ldns_rr_list *rrlist;
struct _zonemd_tree *parent;
struct _zonemd_tree **kids;
unsigned char digest[EVP_MAX_MD_SIZE];
bool dirty;
} zonemd_tree;
#endif
But the actual digest calculation is not that much more complex for fancy
hashtree sutff, IMO. The only difference is what you feed as input to the hash
function. At the non-leaf nodes the input is hash values of the child nodes.
At the leaf nodes the input is the RRs wire format data.
DW
smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fundamental ANAME problems
On 3 Nov 2018, at 23:32, Måns Nilsson wrote: > _http._tcp.example.org. IN URI10 20 > "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/; > > We already have this. We need not build a new mechanism. +1 Patrik signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
I'm also somewhat confused by the quoting in: "In the case of the "SRV" "RR" and "URI" "RR", distinguishing among different types" (and in "defining "RR"s that might" ) - I'm not sure if it is intentional, but it doesn't align with much of the rest of the formatting, and is (IMO) confusing around the first part.) That's xml2rfc being helpful. The xml says those are verbatim strings and it added the quotes. I presume the editors can fix this. Probably nit: Section 2: "Only global underscored names are registered in the IANA Underscore Only the global underscored names "_service1", "_service2", Global table. (From the example, that would mean registering "_service3", "_service4", and "_authority" are registered in the IANA _service1, _service2, _service3, _service 4, and _authority.)" First sentence repeats. In xml it is clear that two lines of old text weren't deleted. I stared at the table of names and I think it's right, but it's the meat of the document and more people looking at it would be good. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
