Re: [DNSOP] Use of CNAMEs for NS Records
On 8/23/22 7:00 AM, Tobias Fiebig wrote: Context: I am currently dealing with academic reviewers claiming that not using CNAMEs for NS is, quote, "[...] by the spec, [..] true, [but] also commonly ignored in practice. Obeying the speed limit is "[...] by the spec, [...] true, [but] also commonly ignored in practice" doesn't mean that speeding is legal. It /MAY/ be an indication that the law / speed limit or RFC / CNAME spec needs to be changed. However there is a process to go about doing both of those things. In the mean time, don't speed. Or at least don't be upset when you get stopped or your CNAME NS records fail to operate as desired. I would personally argue "RFC says no" still holds, and I think you already gave me another good argument to make why exclusion of CNAME NS is valid in our case. I want to say "be liberal in what you accept and conservative in what you send" but "brown M&Ms". I do encourage you to stand your ground and not support CNAMEs for NS records. Or at most call it out as an "undefined behavior" that you will not expend effort to make work. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
On 7/18/23 7:42 PM, George Michaelson wrote: I know, I could submit these to the PSL website directly. I am asking a meta question: do we think that operationally, if a PSL exists, that all ccTLD and TLD should be on it? I'm of mixed opinion. I see the value in having ccTLDs and TLDs on the PSL. But, as you speak to, I think that this choice should be left up to the *TLD operator. I could have asked this on dns-operations, my wondering here is that maybe we need to suggest to ICANN that it's a formalism? My understanding, and hope, -- maybe it's a pedistal -- is that IETF et al. are /technical/ in nature while being as /apolitical/ as possible. To this end I fear that specifying if a *TLD should be on the PSL or not is questionable and could easily become political. Then there is the issue of is the PSL official / formal enough that other things can formally reference it's use? Operationally ... it exists Agreed. Even if the PSL as it exists today disappears tomorrow, the concept of a PSL exists and will be quickly re-produced. So, given it exists, systems are coded to behave against it, and not having SOME ccTLD (and I would posit gTLD) on it, means they don't match as "first class citizens" the behaviour the PSL brings. I agree with the concern and disequality. However I have concerns that we would be meddling in in the *TLD operators business. I could also understand a pushback "somebody else's business" or "take it up with ICANN directly there's no IETF in this" as well as "the CCTLD self manage, nobody tells them what to do" I could see some value in unofficially recommending that *TLDs be placed on the PSL while leaving it up to the PSL operator to choose to do so or not. (the PSL is discussed from time to time here) The recent mailop thread about AOL/Yahoo requiring SOAs and how it relates to the PSL comes to mind. In short, I wouldn't vote against adding *TLDs to the PSL. But I don't think I'd vote for it either. I'd abstain and respect the *TLD operator's choice. Grant. . . . ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Is DNSSEC a Best Current Practice?
Hi, +10 to aggregating current documentation into one place. On 3/10/22 12:04 PM, Paul Wouters wrote: Even better if we would clarify DNSSEC is not an optional part of DNS, but I don’t think you are volunteering for that discussion 😀 Eh ... I'm more interested in aggregating current documentation into one place than I am trying to alter the status quo. I say this because I believe that aggregation / collation of already agreed upon (read: published) /current/ standards is a relatively simple thing and should have minimal objections. Conversely, trying to change / update anything will likely garner (non-trivially) more objections. Perhaps there should be a statement speaking to aggregation / collation as opposed to updating in said document. Aside: Maybe it's just me, but I feel like there is more perceived value in clarifying existing documentation, in the hopes that others will be more likely to adopt current best practices, than there is in updating things. Dare I say it, but I feel some urgency to do this. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Is DNSSEC a Best Current Practice?
On 3/10/22 1:16 PM, Colm MacCárthaigh wrote: I think a single BCP doc is a good idea, but here I'd actually go much further and argue for a significant section in the BCP that acknowledges that it is also a best current practice not to enable DNSSEC. That is objectively the most common practice, and it is very often intentional. I'm not trying to get into what is and isn't best current practice. But I do think that best and common practices often do differ. I also think that just because something is the most common practice doesn't equate to being the best practice. -- History is full of things that were once the most common that we would now agree aren't now and probably weren't at the time the /best/ thing to be done. I think there's a way to frame it and lay out the intrinsic trade-offs between internet stability risks and the security benefits. That framing actually underscores the importance and urgency of all the best practices that can mitigate the stability risks and enhance the security. Agreed. It is important to understand and articulate all (known) aspects of a problem as well as the pros and cons thereto. That might more effectively persuade DNSSEC skeptics. Absent a big change in adoption, a BCP could otherwise seem quite disconnected from reality (TLD-scale outages, stale cryptography) and tone-deaf to the skepticism that's out there. "We hear you" is powerful. We see such disconnects between BCPs (not smoking / wearing seat belts) and people choosing to go against them (by smoking / not wearing seat belts). Such choices don't inherently detract from the veracity of the BCP. -- I know a lot of people that say things like "I know that I should do $THING, but I don't like it, so I choose not do $THING." As much as I dislike it, I have to respect their personal choice. At least up until their choice adversely impacts me / others. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC2317 Question: Resolving cname delegation
On 08/24/2017 09:46 AM, Hector Santos wrote: Not expecting this in my DNS resolver code, I modified the resolver to take the CNAMEs into account and return the host names instead. Was this the correct thing to do, thus providing the same results regardless of the query location? This is one of the gotchas for classless in-addr.arpa delegation. Before I release my updates, I wonder if this was the right thing to do. I prefer to use a different method to do classless in-addr.arpa delegation. Specifically, I ask ISPs to put an NS record for the IP(s) in question pointing to my own DNS server. Then I configure zone(s) that match the full in-addr.arpa name with the PTR in the zone apex. You can have a separate zone (d.c.b.a.in-addr.arpa.) for each IP (a.b.c.d) -or- you can have a single parent zone (c.b.a.in-addr.arpa.) with individual PTR records, much like the ISP normally does. If you do the second method (parent c.b.a.in-addr.arpa. zone) I'd recommend that you have NS records for the other 224 IPs that point to your ISP's name server that is authoritative for the zone. In effect, you are actually delegating the IPs an additional level. I got bit by SORBS not understanding classless in-addr.arpa delegation (since been fixed) more than a decade ago and have never had any similar problems. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC2317 Question: Resolving cname delegation
On 08/26/2017 12:23 PM, Hector Santos wrote: > This was done, at least the first part of providing the ISP the two NS > servers required. They used RFC2317 to setup the cname delegation. On > my servers, I had done what you suggestion with the second method using > a parent c.b.a.in-addr.arpa zone. It all seems to work, except for the > unexpected cname+ptr records with non-authoritive results. If CNAME is still involved, you didn't do what I'm recommending. Suppose that this is the ISP's reverse DNS zone: $ORIGIN . $TTL 3600 2.0.192.in-addr.arpaIN SOA ispdnsserver.example.com. hostmaster.example.com. ( 1234567890 ; serial 3600; refresh 1800; retry 604800 ; expire ) IN NS ispdnsserver.example.com. $GENERATE 1-122 $ PTR somehost.example.com. 123 IN NS mydnsserver.example.net. $GENERATE 124-255 $ PTR somehost.example.com. This would be your reverse DNS zone: $ORIGIN . $TTL 3600 2.0.192.in-addr.arpaIN SOA mydnsserver.example.net. hostmaster.example.com. ( 1234567890 ; serial 3600; refresh 1800; retry 604800 ; expire ) IN NS mydnsserver.example.net. $GENERATE 1-122 $ NS ispdnsserver.example.com. 123 IN PTR myserver.example.net $GENERATE 124-255 $ NS ispdnsserver.example.com. Notice how the ISP is using an NS record instead of a PTR or a CNAME record. The ISP is quite literally delegating DNS responsibility to you, the exact same way that the upstream parent, 0.192.in-addr.arpa., delegated 2.0.192.in-addr.arpa. to the ISP. That is the catch. You are re-using THE EXACT SAME METHOD that is already used, NS delegation. Do NOT use CNAMEs in the parent zone. > Still studying the impact. I was trying to prevent some consistency in > the results in the resolver. In the same way, that its done for > A->CNAME->A results. CNAMEs in reverse DNS have been problematic for me. (See previous email.) > Thanks You're welcome. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
On 07/24/2018 09:08 AM, Petr Špaček wrote: I would recommend you to use subdomain of your public domain. Agreed. The alternative might be to use a different public domain. Nice thing is that this approach doesn't require: - views - forwarding - explicit trust anchor (if you want DNSSEC inside internal network) Public (sub)domain(s) also make it easier to use external / 3rd party CAs. - Rather I've found it difficult to use private / non-public (sub)domain(s) when using public CAs. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
Paul, On 07/24/2018 10:10 AM, Paul Vixie wrote: i also use real domains for my private stuff. but i also use RPZ locally for the internal bindings, Do you leverage anything like Dynamic DNS updates in conjunction with DHCP? If so, how well does that play with the configuration that you're using? not NS RR delegations that i'd have to keep out of my externally-served zone files. Is there a best practice around this method of delegating to sub-domain(s) that are inaccessible to the public? Is it better to return NODATA or NXDOMAIN to global clients querying for host.sub-domain.example.net? Or is there a different error that can be returned to indicate no access? I guess there's always delegating to a server that is inaccessible externally too. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
On 07/25/2018 05:18 AM, Tony Finch wrote: I recommend having an empty public view of your private zone, so that external queries succeed with NXDOMAIN / NODATA. ACK. What is your opinion on blindly grafting the sub-domain onto the parent zone without proper delegation. I.e. internal DNS server hosts internal.example.net and external DNS server returns NXDOMAIN for internal.example.net. I have my doubts about this sort of scheme supporting DNSSEC. - I think it would be better to have a mostly empty zone that is properly delegated that re-use the same DNSSEC keys. I might even go so far as to have the external server be a slave for a specific empty view transferred from the internal server. That way the keys stay internal. Returning REFUSED for a private zone causes retries, and not responding at all causes even worse problems such as EDNS fallback attempts. ACK I haven't tried delegating to RFC1918 addresses, but that is likely to cause similar weirdness. As I type this I wonder about delegating to RFC 1918 address via names in an NS record that are within delegated zone. Thus they would require glue records. Externally I'd omit the glue records. Internally I'd have the records within zone scope along with all the other zone data. I suspect that this may cause odd retry issues too. It may leak some information, but I do think that the hard NXDOMAIN / NODATA is likely cleanest for the DNS protocol. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC7720 and AXFR
On 10/28/2018 10:44 AM, Evan Hunt wrote: As a relatively new consideration, root zone local mirroring (RFC 7706) depends on at least a subset of root servers being able to provide the zone via AXFR. Does root zone local mirroring require that the zone comes from the lettered root servers themselves? Or could it come from another server with the root zone? Possibly a server that one or more operators set up specifically for the purpose? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation into the interior of a zone?
On 12/27/18 1:29 PM, John R Levine wrote: He thinks $GENERATE confuses people. No, $GENERATE is not why he, *I*, prefer to use NS over CNAME delegation. I listed out multiple (2 ~ 3) manually as an example instead of using $GENERATE purely to simplify the example. I've run across many people that don't know what $GENERATE is, particularly if their experience comes from somewhere other than BIND. So, I simply list out the discrete lines that $GENERATE would produce. I think it removes a variable from an equation and simplifies things. The use of $GENERATE or not is independent of CNAME vs NS delegation. Besides, $GENERATE happily works with CNAME as well as it does NS records. $GENERATE 1-4 $ CNAME $.bob.example.net. $GENERATE 5-8 $ NS ns1.example.com. Both work perfectly fine. named-compilezone produces the expected lines. 1.localhost. 604800 IN CNAME 1.bob.example.net. 2.localhost. 604800 IN CNAME 2.bob.example.net. 3.localhost. 604800 IN CNAME 3.bob.example.net. 4.localhost. 604800 IN CNAME 4.bob.example.net. 5.localhost. 604800 IN NS ns1.example.com. 6.localhost. 604800 IN NS ns1.example.com. 7.localhost. 604800 IN NS ns1.example.com. 8.localhost. 604800 IN NS ns1.example.com. Which of the two methods above is easier (or poses fewer questions) to understand by someone who's not familiar with BIND, much less $GENERATE? Don't shoot, I'm just the messenger. I can shoot the messenger with a Nerf gun for reporting the wrong message. Or are we playing a game of telephone? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation into the interior of a zone?
On 12/27/18 12:59 PM, Paul Vixie wrote: in RFC 2317 we do this with CNAME not NS. did the proponent explain why CNAME wasn't suitable for her purposes? Vaguely. I personally find CNAMEs to sub-domains to be sub optimal for various reasons. I have coached MANY (too many?) people through RFC 2317 over the last 18 years. Almost all of them have run into the following issues: 1) RFC 2317 is in some ways too vague. I say this because the people wanting to do classless in-addr.arpa delegation tend to be new, to at least 2317, if not DNS in general and don't understand how it works. As such, RFC 2317 not specifying some details (probably done on purpose to be flexible) tended to make things more difficult for them. 2) RFC 2317 uses the (forward) slash character "/" in some of the examples as part of sub-domain that qnames are being aliased to. (From memory) elsewhere the RFC states that some DNS servers and / or clients might have problems with the (forward) slash character "/" and indicate that a different character may need to be used. 3) RFC 2317 does not clearly stipulate that sub-domain that qnames are being aliased to can be any sub-domain / zone that you want. This leaves people questioning if they have to do some sort of in-addr.arpa like reverse DNS zone or if they can make it a sub-domain of (one of) their main domain(s). 2317 makes some suggestions about using the network, separation character, CIDR prefix length. But (from memory) this wasn't clearly articulated. I also believe there were examples of other methods, thus adding to the confusion. 4) Some DNS servers (MS-DNS) have problems with an 0/16.2.0.192.in-addr.arpa. Or at least their wizards make it seems as if it can't be done and leave it up to the reader to figure out how to do it manually. 5) I've run into many ISPs that refuse to do 2317 but will do NS delegation. 6) I've had to coach ISPs (frequently by proxy) on 2317 to try to get them to understand enough to decide if they will do it. (Frequently they say no after they learn enough, citing "complexity".) 7) I've had much less push back asking for IPs to simply be delegated using standard NS records to other DNS servers. Aside: I believe John was primarily question my recommendation to have different versions of the same zone cross delegating to each other. But it's important to know that when I originally started using NS delegation instead of CNAME delegation I was using separate zones for each and every delegated IP address. This quickly got unwieldy. So I tried with the single zone, found no problems, and have never seriously looked back. - I'm always curious about pros and cons of it. Hence my follow up to John's thread on the bind-users list. I have also run afoul of RBLs that did not know what RFC 2317 Classless IN-ADDR.ARPA Delegation was. Thus their scanners came across my CNAME per 2317 and coughed up a fur ball and black listed servers. While working with the RBL operator (I found them to be quite approachable and responsive when being polite) I learned that their scanners would not have had any problem with the NS delegation. - I believe their specific problem was that they were expecting a PTR record and did not process the CNAME record at all, much less correctly. They stipulated that they were already processing NS records for delegation and would have happily done do and found the requisite PTR. So, I switched to the NS delegation (using discrete zones at the time) and moved on. I heard from the RBL operator about six months later, letting me know that they had retooled a significant portion of their infrastructure to support 2317 and thanking me again for bringing it to their attention. I personally feel like aliasing to a sub-domain is atypical of standard DNS delegation. At least in the in-addr.arpa space. Conversely, using an additional NS record for one more delegation is re-using the exact same methods that were used to get to the qname in question. I felt like NS delegations were cleaner and simpler than CNAME delegations. Of the people that I've helped over the years, telling them to ask their upstream ISP to put in an NS record (something they are more likely used to) and adding a 6 label zone (with the PTR in the apex) to their server worked out MUCH easier. The conversations were ALWAYS shorter, less complex, and clearer. if the old domain-obscenity-checker (DoC) which came out with the domain-information-groper (DiG) back in the 1980's says it's wrong, then it's wrong. Now I want to test NS delegation (both multiple zones and single zone) with DoC and DiG to see what they say. if the specifications don't cover this case, they are incomplete. I won't say how likely (or not) that is, just that it is a statistical possibility. or at least, that's how i do things. Fair enough. With all do respect Paul, how you do or don't do things d
Re: [DNSOP] Delegation into the interior of a zone?
On 12/28/18 3:27 PM, John Levine wrote: I'd think it depends whether invalid delegations bother them, like if, say, ns1.example.com might not be running BIND. You seem to be conflating the two independent issues at hand: 1) Use of RFC 2317's CNAME technique vs the NS technique I'm advocating (be it to the interior or apex of the zone). 2) Use of $GENERATE vs manually creating individual records. #1 is what records to use. #2 is how to create said records. Between them there are four possible combinations. · Use CNAMEs with manual record creation. · Use CNAMEs with $GENERATE. · Use NS records with manual record creation. · Use NS records with $GENERATE. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On 2/14/19 6:51 PM, Paul Vixie wrote: i want the metadata i need to reach and trust assets on my side of any connectivity loss event, to be kept in warm storage, and made subject to trusted invalidation on an opportunistic basis, at the discretion of the authority operators who own the data i have warm copies of. Please explain how "warm storage" relates to priming issues. Does warm mean that it's something you have queried? Or does it also include pertinent (meta)data for interesting things (but not everything) that you've not yet queried? in practice this means DS/NS and DNSKEY/RRSIG and /A from my static trust anchor(s) down to any data i used recently or frequently (or by some other priority scheme), and i want it to look a bit like the single transaction mode of IXFR plus the single transaction mode of NOTIFY. no topology information as to actual connectivity will be modeled or estimated or needed. what matters is whether i can still reach all internet resources on my side of a break in connectivity (whether local or regional or distant), without needing any information that's otherwise only available on the far side of the connectivity break. Does "still reach all internet resources on my side of the break" include things that you've not yet queried for? I'm wondering if a fancier cache of some sort would suffice. Specifically I wonder if BIND (et al) can maintain a FIFO (like) list of QNAMEs, moving the current QNAME to the start of the list, and proactively refreshing the first 10 / 100 / 1000 / pick a number in such a way as to not alter the list position when refreshing. This obviously has a priming problem as a QNAME won't be subject for refresh until /after/ it has been queried the first time. This is why I question your use of the word "warm". Perhaps this can be implemented as part of the existing garbage collection process that remove expired cache entries. If the data to be purged is in the FIFO, then refresh it and cache the results without moving it to the head of the FIFO. The other thing that I might add to this is something to artificially prime the cache by querying for specific names off of a user definable list. How close would something like this be to what you're wanting to see? This would re-use existing mechanism and methodology. It wouldn't see changes in data until after cache expiration. But this is SoP for caches now. thanks for asking; i am happy to clarify. DNS infrastructure should not be centralized, even if its content remains centrally coordinated by ICANN. (block chain people keep telling me that ICANN will be obsolete, but i'm not taking a position on that, only on data resiliency.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] simple question
On 11/13/2015 09:55 AM, A. Schulze wrote: consider a nameserver ns.example.com serving example.com. There is a delegation from com. including glue. Now we add a childzone sub.example.com. served by the same nameserver ns.example.com. should I add a entry in example.com to delegate the subzone to myself? Is the subdomain, sub.example.com, a separate (child) zone? Or is it simply part of the same zone on the same server(s) as the parent domain, example.com? If you are breaking the sub-domain, sub.example.com, out into it's own zone, then yes you need to delegate via NS records. If you aren't breaking the sub-domain into it's own zone, I see no reason for NS records. Remember that zones do not have to line up with (sub)domain boundaries. -- Grant. . . . unix || die ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
