ietf
[Top] [All Lists]

DNS Additional Section Processing Globally Wrong

2009-06-03 21:51:01
... 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. 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>