This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/dns-wg@ripe.net/
Draft on using SRV records to locate whois servers
- Previous message (by thread): Draft on using SRV records to locate whois servers
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Peter Koch
pk at TechFak.Uni-Bielefeld.DE
Sun Apr 28 17:16:42 CEST 2002
Hi Brad, thanks for your comments. Just two short clarifications (I hope :-) > Agreed. In the absence of a searchlist, the standard recursive > search algorithm should be applied. Well, the local resolver's search list would have nothing to do with what we try here, so the resolution process should be independent of it. If I have TechFak.Uni-Bielefeld.DE and Uni-Bielefeld.DE in my search list, that should not alter the way "whois deep.weird.example" is treated. > > for a whois server for the root domain, i.e. it MUST NOT issue queries > > for _whois._tcp. > > Now this I don't understand. We can query for NS records all the > way up to the root zone, and there can be a whois server for the root > zone -- it may only define delegation data for the TLDs, but this is > still valid information). I don't understand why we should never > query for this data, given that it should be the very last query in > the sequence (and first match wins). The contribution to root server load (which suffers from garbage as we will probably learn on Thursday) may indeed be marginal. And you're right, there might be a whois server for the root. But then, "_tcp" would be a TLD and I do not believe it be established, so the queries will be useless. Anyway, this is fine tuning. -Peter
- Previous message (by thread): Draft on using SRV records to locate whois servers
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]