CNAME and TTL
Hi, I am having only a forward only option in bind configuration. When i dig on some host which has CNAME, the cache contains a longer TTL for the CNAME than the TTL for the final resolution of the IP. However, in the example below, the CNAME is queried again when the TTL for a336.g.akamai.net. is up. I was expecting that the TTL for CNAME will be used from the cache and the lookup will not happen again until the TTL has not expired. Is there a way to avoid additional lookups when the value is already present in the cache for CNAME entries. root@titan# dig emp.bbci.co.uk ; DiG 9.8.2rc1-RedHat-9.8.2-14.mlos2.mwg emp.bbci.co.uk ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 27673 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;emp.bbci.co.uk. IN A ;; ANSWER SECTION: emp.bbci.co.uk. 436 IN CNAME emp-live.bbc.net.uk. emp-live.bbc.net.uk. 253 IN CNAME emp.bbci.co.uk.edgesuite.net. emp.bbci.co.uk.edgesuite.net. 3368 IN CNAME a336.g.akamai.net. a336.g.akamai.net. 6 IN A 58.27.124.225 a336.g.akamai.net. 6 IN A 58.27.124.200 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CNAME and TTL
On 06.12.13 15:52, sumsum 2000 wrote: I am having only a forward only option in bind configuration. When i dig on some host which has CNAME, the cache contains a longer TTL for the CNAME than the TTL for the final resolution of the IP. Yes, every record has its own TTL, including every record in CNAME chain. However, in the example below, the CNAME is queried again when the TTL for a336.g.akamai.net. is up. Pardon? I was expecting that the TTL for CNAME will be used from the cache and the lookup will not happen again until the TTL has not expired. When a name is queried, query is processed always the same way - every name of a chain is validated again and missing/expired names are resolved again. Note that records can removed from memory even without expiring, e.g. when memory is full. Is there a way to avoid additional lookups when the value is already present in the cache for CNAME entries. not without violating DNS standard. ;; ANSWER SECTION: emp.bbci.co.uk. 436 IN CNAME emp-live.bbc.net.uk. emp-live.bbc.net.uk. 253 IN CNAME emp.bbci.co.uk.edgesuite.net. emp.bbci.co.uk.edgesuite.net. 3368 IN CNAME a336.g.akamai.net. a336.g.akamai.net. 6 IN A 58.27.124.225 a336.g.akamai.net. 6 IN A 58.27.124.200 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Quantum mechanics: The dreams stuff is made of. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
On Dec 5 2013, Matthew Pounsett wrote: On 2013-12-05, at 01:37 , Mark Andrews ma...@isc.org wrote: Note, named will for the use of TCP in its UDP response. s/for/force/ Always? Regardless of response size? Interesting. What's the rationale for doing it that way? Just to clarify, RFC 1995 says | Transport of a query may be by either UDP or TCP. If an IXFR query | is via UDP, the IXFR server may attempt to reply using UDP if the | entire response can be contained in a single DNS packet. If the UDP | reply does not fit, the query is responded to with a single SOA | record of the server's current version to inform the client that a | TCP query should be initiated. The sense in which BIND forces use of TCP is that when it gets an IXFR request over UDP, it always just replies with the current SOA. It doesn't bother to work out whether an incremental transfer is possible and if so whether it would fit into the UDP payload. Of course, if the client's supplied SOA serial is the same, this response indicates that no zone transfer is needed. -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
On 2013-12-06, at 12:11 , Chris Thompson c...@cam.ac.uk wrote: The sense in which BIND forces use of TCP is that when it gets an IXFR request over UDP, it always just replies with the current SOA. It doesn't bother to work out whether an incremental transfer is possible and if so whether it would fit into the UDP payload. Of course, if the client's supplied SOA serial is the same, this response indicates that no zone transfer is needed. Yeah, the mechanism is clear. I was curious about the why rather than the how. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
