[I am not sure if this has been said yet, I stil have ~130 unread messages, but...]
Tony I strongly disagree. DNS servers function from the stand point of RRsets not individuals RRs like A and AAAA. What you are proposing is similar to not returning A records for a query that used IPv6 network which was discussed on ngtrans a while ago. This would end up splitting the RRset and returning a partial set, which may not be what was required by the requestor. You are limiting the response of the server based on the protocol/addresses used to access it. The only thing that does this now is two-faced DNS or multiple views in bind 9. But, I am not sure that handle muliple sites. -vlad Tony Hain wrote: > > > THere is a mismatch between the DNS perception of 'site' and the > site-local definition of 'site'. The DNS version is much stricter about > physical separation, but there shouldn't be a requirement that DNS > servers for a segment of an AS have to be in differrent SL regions. It > sounds like there is more to do on the DNS operations document... In any > case, the only way a DNS server should return a SL in a response is if > the query was received on a SL. This is the only reasonable way for the > server to know if the answer is usable. If the DNS servers for a given > set of hosts are split across multiple SL zones, then some of the > answers will be global. This is logically the right thing to do from the > DNS query/response perspective, but from the operations perspective, the > servers shouldn't be in separate SL zones. If a particular network > doesn't want to add to the DNS infrastructure, there is no requirement > to populate it with SL addresses. If the routers don't announce them in > the RA, and they aren't in the DNS, they don't get used. That does not > mean we should get rid of them, because smaller organizations will > typically find them useful to minimize the impact of changing providers. > > Tony > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
