In message <AAAB52EF-AD0A-4D3C-9B28-B864F342D933@xxxxxxxxxxxxxxxxxxxxxxxx>, Sab ahattin Gucukoglu writes: > ... it's that, or my reading of RFC 2181 has gone horribly wrong. > > The problem is this: the authoritative servers for a domain can easily > never be consulted for DNS data if the resource being looked up > happens to be available at the parent zone. That is, > bigbox.example.net's address and the RR's TTL can never be as > specified by the zone master unless he or she has control over the > parent zone's delegation to example.net if bigbox.example.net happens > to be serving for example.net. (Registries give you address control, > of course, but often they fix on large TTLs.) > > As far as I can tell, every public recursive server I can reach, > dnscache and BIND9, and one Microsoft cache and one of whatever > OpenDNS uses, all do the wrong thing (TM) and never look up true data > from authoritative name servers. They hang on to additional section > data from the delegating name server and pass this on as truth, the > whole truth, and nothing but the truth to everybody who asks. Except they don't. What you may be seeing is parent servers returning glue as answers and that being accepted. > This > means that if my machine happens to be serving for my domain, I'll > never be able to reduce the TTL to a reasonable value for my dynamic > conditions. Even if, in all seriousness, going ahead with a dynamic > address is a nuisance, is this use of additional data not > fundamentally broken? > > If there is consensus on the wrong behaviour, I'd like it written > somewhere, so I can feel happy about it just being the way it is by > implementation, common sense, performance, or whatever. Then I can > conform to reality by just using a separate name in delegations. > > Alternatively, if *I* wrote a DNS cache, I'd simply use non- > authoritative data, and expect it, only when necessary: as soon as > I've chased whatever referals are necessary, I can throw it away. I > can rely on two things that make this reasonable: (I) that it's the > requested RRs I'm interested in and not the delegation, and (II) that > I can get, and will often get, better additional data from > authoritative name servers that I have no reason not to hang on to > and, as needed, to propagate. Besides, it's easier this way to detect > discrepancies between the delegation and the zone master. > > Cheers, > Sabahattin > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf