In message <[email protected]>, 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
