SRV on multiple subdomains
Hello, I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,...). For A and MX entries, we use a general domain definitions with wildcard but is there a way to do so for SRV without having to define all subdomains (we have several dizains of it) ? We have to define some SRV entries with the same target like : _imap._tcp.server1.example.com IN SRV main.exemple.com _imap._tcp.server2.example.com IN SRV main.exemple.com [...] For example something like _imap._tcp.*.example.com IN SRV main.example.com. I read in a doc that the < * > can only be the leftmost label in the name. Is there an other way to simplify or does I have to add each entry individually? I hope my question is clear enough, it's not easy to explain. Thanks Mat -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV on multiple subdomains
On 14.05.24 13:08, DEMBLANS Mathieu wrote: I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,...). For A and MX entries, we use a general domain definitions with wildcard but is there a way to do so for SRV without having to define all subdomains (we have several dizains of it) ? We have to define some SRV entries with the same target like : _imap._tcp.server1.example.com IN SRV main.exemple.com _imap._tcp.server2.example.com IN SRV main.exemple.com I assume that _imap._tcp should be configurable per domain, so there should not be needed any need for things like _imap._tcp.server1.example.com - you should use _imap._tcp.example.com For example something like _imap._tcp.*.example.com IN SRV main.example.com. I read in a doc that the < * > can only be the leftmost label in the name. correct. Is there an other way to simplify or does I have to add each entry individually? no, but the question is if you really need this. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV on multiple subdomains
Le 14/05/2024 à 15:08, DEMBLANS Mathieu a écrit : Hello, I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,…). For A and MX entries, we use a general domain definitions with wildcard but is there a way to do so for SRV without having to define all subdomains (we have several dizains of it) ? We have to define some SRV entries with the same target like : _/imap./_tcp.server1.example.com IN SRV main.exemple.com _/imap./_tcp.server2.example.com IN SRV main.exemple.com […] For example something like _/imap./_tcp.*.example.com IN SRV main.example.com. I read in a doc that the « * » can only be the leftmost label in the name. Is there an other way to simplify or does I have to add each entry individually? I hope my question is clear enough, it’s not easy to explain. Thanks Mat Avoid any use of wildcard. In the present case you should not need it. And if really needed, do provisioning. Wildcards are a true pandora's box. It is the "XSS" of the DNS. Those who pretend to master all possible present and future practical side effects of a wildcard entry simply denote a lack of humility. Emmanuel. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SRV on multiple subdomains
A part of the subdomains are managed by us, others subdomains by an other entity. So we can't configure a generic target for all subdomains as each entity has its own target for SRV entries. -Message d'origine- De : bind-users De la part de Matus UHLAR - fantomas Envoyé : mardi 14 mai 2024 15:58 À : bind-users@lists.isc.org Objet : Re: SRV on multiple subdomains On 14.05.24 13:08, DEMBLANS Mathieu wrote: >I have a question about configuration simplification for SRV configuration >(maybe it can be applyed for other entries). > >We manage multiple subdomain of a main one (server1.example.com, >server2.example.com,...). >For A and MX entries, we use a general domain definitions with wildcard but is >there a way to do so for SRV without having to define all subdomains (we have >several dizains of it) ? > >We have to define some SRV entries with the same target like : >_imap._tcp.server1.example.com IN SRV main.exemple.com >_imap._tcp.server2.example.com IN SRV main.exemple.com I assume that _imap._tcp should be configurable per domain, so there should not be needed any need for things like _imap._tcp.server1.example.com - you should use _imap._tcp.example.com >For example something like _imap._tcp.*.example.com IN SRV main.example.com. >I read in a doc that the < * > can only be the leftmost label in the name. correct. >Is there an other way to simplify or does I have to add each entry >individually? no, but the question is if you really need this. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Special-use names and RPZ
There are several 'special-use' domain names I'm pondering * invalid. * test. * onion. My read of the RFCs indicate they should result in NXDOMAIN, and not be passed for resolution. RFC 6761 (test. Section 6.2.4 / invalid. Section 6.4.4) caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. RFC 7686 (onion. Section 2.4) where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to look up records for .onion names. They MUST generate NXDOMAIN for all such queries. Is there some reason these should not just be hammered into our RPZ ? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Special-use names and RPZ
On Tue, May 14, 2024 at 2:34 PM John Thurston wrote: > > There are several 'special-use' domain names I'm pondering > > invalid. > test. > onion. > > My read of the RFCs indicate they should result in NXDOMAIN, and not be > passed for resolution. > > RFC 6761 (test. Section 6.2.4 / invalid. Section 6.4.4) > > caching DNS servers SHOULD, by default, generate immediate negative responses > for all such queries. > > RFC 7686 (onion. Section 2.4) > > where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to > look up records for .onion names. They MUST generate NXDOMAIN for all such > queries. > > Is there some reason these should not just be hammered into our RPZ ? If RFCspeek SHOULD and SHOULD NOT mean "do whatever you feel like doing" (ref RFC 2119 Key words for use in RFCs to Indicate Requirement Levels) So if you feel like adding them to your RPZ file go right ahead :) Regards, Lee -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Special-use names and RPZ
> On 15 May 2024, at 04:34, John Thurston wrote: > > There are several 'special-use' domain names I'm pondering > • invalid. > • test. > • onion. > My read of the RFCs indicate they should result in NXDOMAIN, and not be > passed for resolution. > RFC 6761 (test. Section 6.2.4 / invalid. Section 6.4.4) > >> caching DNS servers SHOULD, by default, generate immediate negative >> responses for all such queries. > > RFC 7686 (onion. Section 2.4) > >> where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to >> look up records for .onion names. They MUST generate NXDOMAIN for all such >> queries. > > Is there some reason these should not just be hammered into our RPZ ? Because despite what you quote above, having a resolver generate negative results without appropriate NSEC and RRSIG records actually causes problems when they are sent by validating clients. Having a local copy of the root zone and returning answers from that suppresses the traffic and the answers are verifiable. > -- > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users