Enjoy unlimited access to all forum features for FREE! Optional upgrade available for extra perks.

Nominet Maintenance Reminder

Discussion in 'Drop catching Domain Names' started by ukbackorder, Jan 18, 2021.

  1. DJ

    DJ Well-Known Member

    Joined:
    Jul 2019
    Posts:
    1,774
    Likes Received:
    203
    We have been led to believe it is legit so unless BHD is being punished for something else, then it might be that he is trying to lie low.

    The thing that confuses me is that if 2 tags are working together isn't that collusion and against Nominets terms even if the method is legal?
     
    • Agree Agree x 1
  2. Domain Forum

    Acorn Domains Elite Member

    Joined:
    1999
    Messages:
    Many
    Likes Received:
    Lots
    IWA Meetup
     
  3. ukbackorder

    ukbackorder Active Member ukbackorder.com
    Bronze Member

    Joined:
    May 2020
    Posts:
    785
    Likes Received:
    147
    DAC is separate. You still only have your normal connections - the tag is irrelevant as all your tags share the same DAC quota. However there is no point using the DAC as a contested domain is already registered before you see the N. There are 2 ways of doing it and both would benefit from more EPP connections (hence people getting more and more tags). There is either a domain specific EPP command which uses no quota and somehow indicates a change in status of a domain or there is something that can be polled and produces a timing delay when a domain might drop. You could act on that timing delay to fire off a check or create. The more connections you have the more things you can be doing at the same time. It's just a matter of finding the command that produces a result you can act on. EPP creates are aggregated. Obviously this could be barking up the wrong tree entirely :) However testing shows that the DAC is most probably out with sought after domains spotted changing in less than 5ms. So leaves only EPP, DNS, and whatever other services nominet might be running to get the trigger. It should be noted that none of that is a breach of AUP.
     
    Last edited: Jan 23, 2021
  4. webber

    webber Active Member

    Joined:
    Sep 2019
    Posts:
    766
    Likes Received:
    235
    It's a grey area... As long as someone is using someone else's code without any input into what domains to catch etc, then that is fine, similar to how hosted catching and revenue sharing is allowed.
    Could there be an EPP command that is part of the EPP standard but not documented by Nominet?
    I get what you're saying, since you can only poll at max 60ms interval it will seem like the domain is always registered even if you get the N. But if someone could abuse the DAC by somehow managing to circumvent the usage calculation, then they could poll from multiple servers every few ms (at least in theory).
     
  5. ukbackorder

    ukbackorder Active Member ukbackorder.com
    Bronze Member

    Joined:
    May 2020
    Posts:
    785
    Likes Received:
    147
    There could be but nominet say there isn't.
    You don't have to poll every 60ms. You can poll as often as you want - you just can't do it for long before you have to wait for the rest of the quota period. If you are lucky enough that the domain drops in that time you can get an idea of the speed of changing. That's how I have seen domains (only three times in a few weeks though) change in less than 5ms. But I discount the DAC anyway. It's only useful for chasing domains that won't be highly sought after.
     
  6. webber

    webber Active Member

    Joined:
    Sep 2019
    Posts:
    766
    Likes Received:
    235
    So you're suggesting there is a trigger that will flag that the domain is about to drop at which point you run DAC at full speed.
    If there is such a reliable trigger why not just fire a short burst of preemptive create commands?
    Of course if the trigger is unreliable then it would make more sense to validate it with DAC.
    So an unreliable trigger might be a sudden latency change in an EPP command for example.
    <domain:info>, which is not subject to AUP, always returns the same result, but maybe it's the time it takes that is the trigger?
    I might just run a test... how many such queries per seconds would you say you can run before you upset the folks at Nominet?
     
  7. ukbackorder

    ukbackorder Active Member ukbackorder.com
    Bronze Member

    Joined:
    May 2020
    Posts:
    785
    Likes Received:
    147
    *Exactly* my point. No DAC needed.
    I don't think nominet would get upset at all if there's no breach of AUP going on. The EPP is already getting hit hundreds of times per second. Now you just need to figure out what they're looking for.
     
  8. webber

    webber Active Member

    Joined:
    Sep 2019
    Posts:
    766
    Likes Received:
    235
    When the DAC caching bug was in use, what kind of latency changes did you see then that would constitute a trigger?
    I'm just trying to get an idea of what timing variations might happen...
     
  9. ukbackorder

    ukbackorder Active Member ukbackorder.com
    Bronze Member

    Joined:
    May 2020
    Posts:
    785
    Likes Received:
    147
    You have to test. There are multiple factors. Of course it might all be wrong. But ask yourself why people need more than one legitimate tag.. for what benefit. And why domains seem to be registering before the DAC updates. And why there are so many EPP commands being run. All points one way.
     
  10. super-whois

    super-whois Active Member

    Joined:
    Oct 2008
    Posts:
    347
    Likes Received:
    86
    This is just speculation, but whilst a domain is in the process of being deleted, then there will be a lock on the database for that entry, resulting in a noticeable delay to all queries for that name. For an error such as "the domain is not on your tag", then the database row needs to be checked that the TAG matches.

    If this is the case, then I think Nominet could close this flaw quite quickly, by adding an index on the (domain, tag) pair.
     
    Last edited: Jan 23, 2021
  11. webber

    webber Active Member

    Joined:
    Sep 2019
    Posts:
    766
    Likes Received:
    235
    Some early results seem to be all over the place in my case: from 6 to 15ms, but mostly 7 or 8ms
     
  12. webber

    webber Active Member

    Joined:
    Sep 2019
    Posts:
    766
    Likes Received:
    235
    First, a word of caution:
    I tried <host:create> on a dropping domain and after about 1000 of V293 Name server is invalid - parent domain does not exist, it turned into V299 You have exceeded usage limits for operations which fail due to the non-existence of superordinate domains. You will be blocked for 24 hours.

    I ran these tests on dmc.uk from the same server, so timestamps are in sync.
    These are just some quick test on a sample of ONE, so not sure any meaningful conclusions can be drawn.

    The DAC was running at about 60ms interval:
    In parallel I had an EPP connection running <domain:info> queries on the same domain every aprox 10ms which always returns
    'V096 Domain name is not registered to your tag' no matter what domain you use, whether it is available, registered, or suspended, if it's not on your tag.
    And another EPP connection running <domain:delete> at same interval which always returns V096
    There are very clear spike in latency both with <domain:info> and <domain:delete>, but they happened at about 23:42:09.600 which is at least 10ms after the domain became available according to the DAC

    I checked a few seconds before as well but couldn't notice any obvious spikes

    Any thoughts?
     
  13. super-whois

    super-whois Active Member

    Joined:
    Oct 2008
    Posts:
    347
    Likes Received:
    86
    Your EPP times appear to be received times, could the DAC times be sent times?
     
  14. timter51

    timter51 Well-Known Member

    Joined:
    Oct 2012
    Posts:
    1,331
    Likes Received:
    87
    The EPP slowdown could be everyone still using DAC (which is a lot) sending off all their EPP create commands.
     
  15. webber

    webber Active Member

    Joined:
    Sep 2019
    Posts:
    766
    Likes Received:
    235
    All timestamps, including DAC, are received time. My DAC RTT is very consistent at 3ms
    Indeed, the epp slowdown corresponds to a spike in <svTRID> counter from an almost clockwork 4 per each 10ms, to over 40. But even though the high number of EPP requests is sustained for almost 100ms the EPP latency recovers quite fast.
     
  16. cyberpunk United Kingdom

    cyberpunk Active Member

    Joined:
    Jul 2019
    Posts:
    151
    Likes Received:
    28
    @webber nice work.

    Are you sure those EPP times are correct? My DAC RTT is 1.8ms, but I only manage 48ms for the domain:info command. I've tried from two different data centres. EPP hello command also measures the same.
     
  17. super-whois

    super-whois Active Member

    Joined:
    Oct 2008
    Posts:
    347
    Likes Received:
    86
    Is that for the command only, or including the login on a new connection? 48ms seems rather high!
     
  18. cyberpunk United Kingdom

    cyberpunk Active Member

    Joined:
    Jul 2019
    Posts:
    151
    Likes Received:
    28
    Just for the command! Tbh I just always assumed EPP response times were quite high. I've been concentrating on DAC too much I think :)
     
  19. ukbackorder

    ukbackorder Active Member ukbackorder.com
    Bronze Member

    Joined:
    May 2020
    Posts:
    785
    Likes Received:
    147
    Nominet added an artificial delay like the time delay dac. I heard they also added delays to the whois and whois2. This suggests they don't know what's going on but don't think it should be running the way it is.
     
    Last edited: Jan 24, 2021
  20. webber

    webber Active Member

    Joined:
    Sep 2019
    Posts:
    766
    Likes Received:
    235
    I never explicitly measured RTT for DAC before this, but looking at logs from past days I see the timestamps between <greeting> <login> and <hello/> are 5 to 10 ms apart. Since you have a better DAC RTT your problem is not the route latency but probably the way you read and write to the socket.
    Well that's shocking. How can you have full control and full logs and not work out what going on!? Weren't they supposed to be specialists in something... I can't remember what it was... cyber-something? Ah, yes, cybersecurity! Anybody knows what that means cause Nominet don't seem to know?
     
  21. lazarus

    lazarus Super Moderator Staff Member

    Joined:
    Feb 2013
    Posts:
    1,485
    Likes Received:
    409
    One way to fix it would be to for nominet to aggrigate the create commands (1 per TAG) then randomise them within 200ms blocks.
    This would resolve everything outside of multi tagging.

    Job done