Mantis Bugtracker

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000049 [MyDNS-NG] Global minor have not tried 2010-03-21 16:13 2014-08-07 21:05
Reporter jorge View Status public  
Assigned To jameno123
Priority normal Resolution no change required Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version Product Version 1.2.8.31
  Target Version 1.2.8.32 Product Build
Summary 0000049: Multiple A records share the same TTL, instead of their own
Description I've found something:

A zone named: zone.pt

with two A records, will put out always the lowerest values for the TTL

www1 IN A 60 192.168.1.1
www1 IN A 100 192.168.1.2


host -v -t a www1.zone.pt

*will* show on both output's the TTL of 60, and not the matching TTL for each record.
Steps To Reproduce
Additional Information
Tags No tags attached.
Attached Files

- Relationships
has duplicate 0000059closed Two A records for the same value responds the lowerest TTL value always in a query 

-  Notes
(0000167)
itamarjp (developer)
2010-10-31 03:04

I will try to investigate this when I have some time.
(0000207)
jameno123 (administrator)
2014-08-07 20:41

Confirmed this with my active running server. I am not sure if this is proper or not. I would think that you would only want to respond with "one" ttl and that mis-matched ttls could cause caching problems on downstream servers. Need to review the RFC and see what is the suggested course of action here.
(0000208)
jameno123 (administrator)
2014-08-07 20:56

From what I can tell (in RFC:1035) there is no limitation that all RR responses must have the same TTL.

The only statement is that an inverse query shall perform the following:
"When the response to an inverse query contains one or more QNAMEs, the
owner name and TTL of the RR in the answer section which defines the
inverse query is modified to exactly match an RR found at the first
QNAME."

Therefor, I am going to attempt to track down this code and make MyDNS-ng respond with differing TTL values (unless someone can point out an RFC that states otherwise).
(0000209)
jameno123 (administrator)
2014-08-07 21:03

Looks like I may have spoke too soon -- after further review MyDNS actually responds correctly, however host and dig show incorrect data after being resolved via a caching resolver. This bug may actually be inside of BINDs caching resolver.

========================================
====== DIRECT VIA NAMESERVER ==========
========================================
[james@localhost ~]$ host -v -t a moo.example.com ns1.examplehost.com
Trying "moo.example.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8309
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;moo.example.com. IN A

;; ANSWER SECTION:
moo.example.com. 3600 IN A 4.3.2.1
moo.example.com. 600 IN A 1.2.3.4

========================================
====== VIA CACHING NAMESERVER ==========
========================================
[james@localhost ~]$ host -v -t a moo.example.com
Trying "moo.example.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30864
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 12

;; QUESTION SECTION:
;moo.example.com. IN A

;; ANSWER SECTION:
moo.example.com. 525 IN A 4.3.2.1
moo.example.com. 525 IN A 1.2.3.4

Going to close this as not our bug. :(

- Issue History
Date Modified Username Field Change
2010-03-21 16:13 jorge New Issue
2010-10-31 03:04 itamarjp Note Added: 0000167
2010-10-31 03:06 itamarjp Relationship added has duplicate 0000059
2014-08-07 19:04 jameno123 Status new => assigned
2014-08-07 19:04 jameno123 Assigned To => jameno123
2014-08-07 19:05 jameno123 version => 1.2.8.31
2014-08-07 19:05 jameno123 Target Version Trunk => 1.2.8.32
2014-08-07 20:41 jameno123 Note Added: 0000207
2014-08-07 20:41 jameno123 Status assigned => confirmed
2014-08-07 20:56 jameno123 Note Added: 0000208
2014-08-07 21:03 jameno123 Note Added: 0000209
2014-08-07 21:05 jameno123 Status confirmed => closed
2014-08-07 21:05 jameno123 Resolution open => no change required


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker