Re: [dns-operations] How should work name resolution on a modern system?
--- Begin Message --- Vix said: > https://www.icann.org/en/system/files/files/sac-053-en.pdf Yep, thanks for bringing it up. Genuinely appreciated. I'm aware "SSAC also recommends that the use of DNS resource records such as A, , and MX in the apex of a TopLevel Domain (TLD) be contractually prohibited where appropriate and strongly discouraged in all cases," yet still note that saying "getaddrinfo should not result in single label 'A' or '' DNS queries" is a meaningful policy change to an API that's older than some of the people on this mailing list. Also, to not get too far down the rabbit hole, there are the finer points of what "single label" means. My cited example had an explicitly included the root label in presentation format, so as not to be a "dotless domain" as described in SAC53, and also not a single label. Of course the on-the-wire format that getaddrinfo uses can only use a single label when querying qtypes at the root label; any TLD is two labels, at least as far as reputable sources like BIND 9's dns_name_countlabels is concerned. That said, we're in broad general agreement. I wouldn't run a TLD that way either, for the reasons that SAC53 describes. I'm still not comfortable saying that getaddrinfo or any other API (eg, getdns) should just block it, at least not without some configurability around it, and with a clear error condition for what it objects to. (That my VPN DNS just says SERVFAIL is bollocks.) --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
--- Begin Message --- Vladimír Čunát writes: > If the root zone is unchanged, many names could be hidden before > reaching root servers - by DNSSEC aggressive caching and/or various > local-root variants. (I'm not sure if we can well measure the extent to > which this happens.) That's an interesting observation. I'm inclined to think (with no data to back it up) that the penetration of DNSSEC is sadly still not deep enough that you'd still see plenty of leakage even in the presence of aggressive NSEC. I know there's data that shows aggressive NSEC does have an positive impact on reducing garbage queries, but also that plenty of garbage still does get through. Ditto local roots. This feels like something Geoff Huston probably has some kind of data about, but a cursory search didn't turn it up. I personally run a local root on my home system, but how prevalent are they? That said, I'm not really just trying to wave off the problems those two scenarios present. I accept that the only way to really capture all of these queries into the global DNS is via a delegation, and just still wonder whether RSS logging wouldn't be good enough to give adequate observations of potential collision problems. Especially because each of the suggested configurations presented originally also have their own problems, as you have already observed. Sounds like at least the two options to synthesize NXDOMAINs for all labels at the delegated authority are worth some lab tests for major resolvers to document just how they'd respond in the presence of the suggested synthesis. Full disclosure: I'm in the "preserve NXDOMAIN" camp, based in part on having worked in the past with systems where the difference between NXDOMAIN and NOERROR/NODATA was significant. I do not knowingly work with such systems now though, so can't make any sort of strong claim as to what would currently be impacted. Well I guess that's not completely true, I *do* regularly encounter the problem with DNSSEC Black Lies, and grumble and mutter every time I do. That's more of a human interface issue though, not a programmatic one. --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations