Re: Determining Which Authoritative Sever to Use
I will say edge DNS servers reduce client config complexity, even if you have DHCP, and increase resiliency of the initial resolver. Where it's true with DHCP you can change the DHCP server options it doesn't help if someone just got a 4 day lease and then the DNS server dies. Additionally the abstraction layer makes patching and decom of DNS servers much easier. No config to chane just kill the box. Perhaps this is less of a concern I'd you are running a smaller environment but when you are running 400 to 500 servers in a variety of roles globally it becomes a valuable resource. On Tue, May 10, 2022, 5:49 PM Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 5/8/22 5:58 AM, Tony Finch wrote: > > Regarding anycast, it isn't necessary for internal authoritative > > servers unless your organization is really huge (and probably not > > even then): it is simpler to just use the DNS's standard reliabilty > > features. All you need to do is have more than one authoritative > > server for each zone. > > I don't know if it's a requirement for the OP or not, but Windows used > to reach out to the MName server to perform dynamic updates. So there > might be some merit to the name of the MName server to be a pseudo name > that resolves to an anycasted address, thus clients try to perform the > dynamic update to the closest instance of the anycast / (pseudo) MName > server. > > Aside: Years ago, BIND secondaries would happily forward such dynamic > updates the real primary MName server. > > Further aside: The last time I looked, MS-DNS ADI zones would forge the > local server's name as the MName to cause this type of client redirection. > > > On the other hand, anycast is a good way to improve the availability > > and maintainability of your resolvers, because your users' devices > > talk directly to them, and if they don't work there might as well > > not be an Internet connection. > > I agree that anycasted service points make administration somewhat > simpler. However I do question the /need/ for such flexibility when > things like DHCP are likely used for client configuration and can > therefor manage most things automatically. > > > > -- > Grant. . . . > unix || die > > -- > 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
Re: Determining Which Authoritative Sever to Use
On 5/8/22 5:58 AM, Tony Finch wrote: Regarding anycast, it isn't necessary for internal authoritative servers unless your organization is really huge (and probably not even then): it is simpler to just use the DNS's standard reliabilty features. All you need to do is have more than one authoritative server for each zone. I don't know if it's a requirement for the OP or not, but Windows used to reach out to the MName server to perform dynamic updates. So there might be some merit to the name of the MName server to be a pseudo name that resolves to an anycasted address, thus clients try to perform the dynamic update to the closest instance of the anycast / (pseudo) MName server. Aside: Years ago, BIND secondaries would happily forward such dynamic updates the real primary MName server. Further aside: The last time I looked, MS-DNS ADI zones would forge the local server's name as the MName to cause this type of client redirection. On the other hand, anycast is a good way to improve the availability and maintainability of your resolvers, because your users' devices talk directly to them, and if they don't work there might as well not be an Internet connection. I agree that anycasted service points make administration somewhat simpler. However I do question the /need/ for such flexibility when things like DHCP are likely used for client configuration and can therefor manage most things automatically. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: "Length"-output in DNSSEC-Policy state-files vs. "Key Length"-output on dnsviz.net
Tom wrote: > I'm wondering about the value of the "Length"-field in the dnssec-policy > state-file output, which results in "Length: 256" for domains, which are > signed with algorithm 13 (ECDSAP256SHA256) That's the size of the cryptographic modulus, i.e. the size of the numbers in the guts of the cryptographic algorithm. > and the "Key length"-output for the domain on "dnsviz.net" (ZSK or KSK), > which results in "Key Length: 512". For P-256 the public key needs two coordinates to identify the point on the curve, so it's twice the nominal size of the algorithm. DNSviz is not being entirely consistent here, because RSA public keys also require a few more bits than their nominal size (for the public exponent), but DNSviz shows their nominal size rather than the size of the public key blob in the DNSKEY record. (The public exponent is usually 65537, which is why RSA keys typically start AwEAA rather than being completely random.) -- Tony Finch(he/they) Cambridge, England Trafalgar: Northerly or northeasterly 3 to 5, but easterly 5 to 7 in far southeast. Slight or moderate, occasionally rough later in north. Fair. Good. -- 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
